I'm using phpdotenv package to setup env in wordpress project
env file
ENVIRONMENT=production
DB_NAME=
DB_USER=
DB_PASSWORD=
I need to add if function in htaccess to do the https redirection based on ENVIRONMENT.
currently I could not get env value in htaccess.
"phpdotenv" is a PHP package. It processes the .env file too late for the variables to be accessible from .htaccess. (.htaccess is processed before PHP gets to handle the request.) So, what you are trying to do is not possible.
You would need to do it the other way round. ie. Set the environment variables in .htaccess (or preferably the server config), which will then be accessible to both PHP and .htaccess.
I need to add if function in htaccess to do the https redirection based on ENVIRONMENT.
There are often other elements of the request that can be used to determine whether you are on production or not. eg. the requested hostname, server IP address, installed module, existence of a specific file etc. Although this is more commonly achieved by setting an env var (or Defineing a "true" server var) in the main server config and checking for this (or absence of this) in .htaccess.
Related
Symfony 4 resigns on app.php and app_dev.php front controllers. Now it will be only one index.php. We can manipulate dev and prod environment in .env file. Please tell me is it only one way to change environment? I can't do that from the browser (as it was previous app and app_dev files)?
You control what is in the index.php file, so you can arrange to include a different env file according to the rules that you decide.
For example, you can set a variable in the Apache vhost or Nginx FastCgi configuration, based on the URL you are visiting from - such as APP_ENV=/home/myname/app-name/dev.env or on a live server: APP_ENV=/etc/app-name.prod.env set as you like, or you could list both of them in the index.php and choose which one from there - although taking the option out of the code and setting it in a server configuration would probably be safer in the long term.
I'm implementing something like this to let one service allow access to separate upstream service in nginx.
Briefly: A Rails app sets an HMAC cookie, which is then checked by some Lua code thanks to an access_by_lua directive in nginx.
To generate and verify the cookie, both Rails and nginx-Lua must of course share a secret key. I've tried setting this up as an environment variable in /etc/environment.
To make the var available in Rails, I had to fiddle with Unicorn's init script a bit. But at least that script is contained within the project, and just symlinked into place.
Meanwhile, to get at the variable in Lua, I do something like this: os.getenv("MY_HMAC_SECRET"). But in order for Lua to have access to that when running under nginx, it must first be listed using the env directive in the main nginx config.
So now, I'm feeling like my configuration is being spread out all over the place:
in /etc/environment (outside my project)
in /etc/nginx/nginx.conf (outside my project)
in unicorn's init script
in my site's nginx vhost config
It's starting to seem a little ridiculous just to make a simple string accessible in multiple places...
Is there a simpler way to do this? Honestly, the easiest way I can think of is hardcode it in the 2 places I need it, and be done. But that sounds nasty.
Better to put it only in the two places it's actually needed, in the two respective configuration files, than in the global environment where every process has access to it, as you have it now.
I would use init_by_lua directive in your vhost config.
init_by_lua 'HMAC_SECRET = "SECRET-STRING"';
server {
# and so on
}
So you'll have you secret in two places, but both in your project (if I understand correctly and vhost config is in your project).
You can even use init_by_lua_file and make some efforts to read and parse that file in your unicorn init.
I'm looking for a way to expose my test environment via a subdomain. Basically, I want to do the equivalent of the console --env "test" via URL. So someone accessing http://example.com will get the production site, but the external testers can go to http://test.example.com and will get the test environment, with test database and everything.
I thought just using SetEnv ENV "test" in my apache config would do the trick, but apparently it doesn't.
I'm fairly sure this is a pretty common thing, so can someone guide me to the solution?
It's really weird that you're trying to access test environment through url, but I'll guess you need some special configuration for WebTestCases.
You need to create app_test.php file in web directory, and boot kernel with 'test' environment parameter. To see how to do it, check out already available app.php and app_dev.php files.
After that, setup your apache to aim for app_test.php when you hit your url. Also have in mind that you will probably have to make apache ignore .htaccess because it will point it to app.php. You can do it using AllowOverride None.
I have a DV 4.0 server on media temple which is setup with nginx as a reverse proxy to apache. I want to configure some far future expires headers (using location blocks) and other settings for my (multiple) domains running through nginx.
Normally this wouldn't be an issue, just create a common set of rules and include them in a server {} block. However, Plesk creates and updates the server {} blocks automatically in separate files, meaning any changes made in these files are wiped out.
Ideally I'd like a way to set up a generic server {} block that gets applied all servers as defaults, but if this doesn't exist I'd like to know how to add custom directives within Plesk so they don't get wiped out when it rewrites the files.
Check this page
Yoг can customize default nginx virtual hosting template:
mkdir /usr/local/psa/admin/conf/templates/custom/domain
cp /usr/local/psa/admin/conf/templates/default/domain/nginxDomainVirtualHost.php /usr/local/psa/admin/conf/templates/custom/domain/
add or change what you need in /usr/local/psa/admin/conf/templates/custom/domain/nginxDomainVirtualHost.php
/usr/local/psa/admin/bin/httpdmng --reconfigure-all # to apply new configuration for all domains
We have a basic drupal multi-site installation on a RHEL (RedHat) server.
For some reason when viewing the site, the asset URLs (CSS/JS) all point to the wrong subdomain.
Our site URL: http://drupal.sandbox.domain.com the drupal index page loads up with asset URLs being written as: http://drupal.sandbox.sandbox.domain.com.
Why would drupal add in the extra .sandbox subdomain?
The .htaccess file has been left as the default, also attempted to set RewriteBase to /, but there was no change. The sites/default/settings.php file has the base_url set to: $base_url = 'http://drupal.sandbox.domain.com' but Drupal is overwriting this somewhere. Setting the $base_url to the IP of the server causes the assets to be linked to the correct location (using the IP rather than the actual domain), but this is not ideal.
I've tested using the same configuration on an Ubuntu Server without any problems. I'm not sure exactly how to track down the cause of this problem.
EDIT: It seems that the server is resolving the domain and immediately overwrites the variable containing a string of the URL.
e.g.:
$base_url = 'http://drupal.a.domain.com'
die($base_url); // shows: http://drupal.sandbox.a.domain.com
This is not a Drupal-specific problem. This can easily be checked by creating a standalone PHP page and using the same code to test. Being that the variable is overwritten immediately after it is set shows that PHP/Apache is the one doing the overwriting.
It is possible for Apache to overwrite input and output. See: What would cause PHP variables to be rewritten by the server?