Welcome Guest, Not a member yet? Register   Sign In
Working with Configuration Files
#1

The quote below is from the CI v4 documentation. Specifically, from the last paragraph of the Handling Different Environments section.

I want to know if the line I put in bold is accurate. I don't see anything in the source code that would make the statement true.

Quote:When your application runs, this file will be automatically loaded and the variables will be put into the environment. This will work in any environment except for production, where the variables should...

Perhaps the sentence relates to a past, possibly abandoned goal and the docs have not caught up?
Or is it a reference to a yet-to-be-implemented behavior?

(Also possible: I completely misunderstand what's being said.)
Reply
#2

Thank you for pointing that out. I just pushed up a change for that page. But basically - the .env file is loaded in all environments.
Reply
#3

(This post was last modified: 05-29-2018, 07:09 AM by dave friend.)

A follow-up question.

So, if I understand correctly, given the very typical development + production environments setup, each would need their own .env file. That feels a bit fragile to me because it would be far too easy to accidentally overwrite the production version with the dev version during an FTP upload for instance. (Something I used to do on a regular basis with config.php before I figured out how to properly handle multiple environments under v3.  Blush )

Is there any way to leverage the /Config/Boot environment specific files to manage values as set in the Config\App, Config\Database, etc. namespaces?
Reply
#4

The Config/Boot options happen early enough it's possible that you could do that, though I've never tried something like that honestly. If you're concerned about it being fragile, you can always use other ways to set environment variables on your server, like through bash profiles, etc, and not use the .env file itself. Though, personally, I'd find ways to avoid using FTP for deployment, if possible.
Reply
#5

(05-29-2018, 07:06 AM)dave friend Wrote: A follow-up question.

So, if I understand correctly, given the very typical development + production environments setup, each would need their own .env file. That feels a bit fragile to me because it would be far too easy to accidentally overwrite the production version with the dev version during an FTP upload for instance. (Something I used to do on a regular basis with config.php before I figured out how to properly handle multiple environments under v3.  Blush )

Is there any way to leverage the /Config/Boot environment specific files to manage values as set in the Config\App, Config\Database, etc. namespaces?

I'm not sure if I understand you correctly, - but I may mention an implementation which covers my needs very well. I've an app which I deploy on multiple sites, - which has different configurations. I've customized the index.php. Based on a logic where I look for a folder under config which has a name equal the current hostname using the gethostname() function. If the "hostname" folder exist, - all configuration files are read from this folder. If the folder doesn't exist, - default config files are read from /config. I feel this is a very flexible solution.

Attached Files Thumbnail(s)
   
Reply
#6

I downloaded CI4 to check out how it might handle a multi-environment and multi-domain setup.  I haven't used CI since CI2 so felt a bit out of touch, but suspected CI4 would be a winner.  I scoured this forum and the wider web for tips on how to set this up.  Unfortunately, the tips around CI3.x are not particularly helpful if you're relatively new to recent versions of CI... and the tips for CI4 on this particular aspect of configuration are incomplete.  This is not criticism.  I'm a long-standing member of the open-source community, so just sharing my experience, which is fairly typical of major new framework release.  I got there in the end, so I thought I would add a little more insight so that anyone else grappling with this setup might find it a little easier than I did.

Using .env turned out to too fiddly, given differences between our particular dev and live environments (win v unix).  It just wasn't versatile enough.  However, much depends on the nuances of what you're trying to achieve and how much or how little interoperability is required between the various domains/modules.  In our case the interoperability requirements are high.  I found that the combination of Apache directiing all requests to pubic/index.php, the customisation of public/index.php and the introduction of a new Domain class to handle initial routing to dedicated application folders, with fallback to a default application setup - all before loading system/bootstrap.php - proved to be the most efficient and manageable solution. 

Overall impressions of CI4 and this community so far: Wow! Really good! Hats off to you guys.
Reply
#7

(05-29-2018, 07:26 AM)kilishan Wrote: The Config/Boot options happen early enough it's possible that you could do that, though I've never tried something like that honestly. If you're concerned about it being fragile, you can always use other ways to set environment variables on your server, like through bash profiles, etc, and not use the .env file itself. Though, personally, I'd find ways to avoid using FTP for deployment, if possible.

Wouldn't it be simpler to support several .env files?

production.env
development.env
etc.

It would be great!
Reply
#8

(03-06-2024, 10:41 AM)b126 Wrote: Wouldn't it be simpler to support several .env files?

production.env
development.env
etc.

It would be great!

The problem with supporting multiple env files is that it encourages devs to save those in their git repositories, which is a horrible idea from a security standpoint. Since these files often include security credentials for various platforms, they should never be committed into a version control system because they're much easier for people to find and abuse. Instead, they should only be placed on the server they have the credentials for. That way someone would need access to the server's file system to get at your credentials. And if they've gotten that far you've likely got other issues, too.
Reply
#9

(03-06-2024, 12:24 PM)kilishan Wrote: The problem with supporting multiple env files is that it encourages devs to save those in their git repositories, which is a horrible idea from a security standpoint. Since these files often include security credentials for various platforms, they should never be committed into a version control system because they're much easier for people to find and abuse. Instead, they should only be placed on the server they have the credentials for. That way someone would need access to the server's file system to get at your credentials. And if they've gotten that far you've likely got other issues, too.

Pushing .env files to git is considered dangerous, you're right, but pushing one or more of them makes little difference to me. I don't push any of them.
Reply
#10

That's why you push env file to repo as placeholder, without real secret info filled in, just for main reference
and use .env in local through .gitignore, with all info filled in.

I can't understand why this question is still coming up. It is so obvious and basecally the most secure way of this feature in general
Reply




Theme © iAndrew 2016 - Forum software by © MyBB