I’m not even sure where to start explaining this bug, because it has a lot of moving parts. But I’ll give it a shot.
Background information:
We’re running mautic 2.0.1 in a Docker container on an Elastic Beanstalk server on AWS. Requests are forced to be HTTPS (which works), but all requests come to the Docker container on port 80. A load balancer receives the request on 443, and forwards into the Nginx server on port 80 which proxies the request to the Docker container on port 80.
Also, this was working yesterday before I added some new themes to mautic, and since then has stopped working. But I know this really isn’t all that helpful. And rolling back the changes, while possible, doesn’t help because all the changes were just to add in 2 new themes to the deployment.
The Docker container itself is Apache 2.4 and PHP 5.6 and has all of the necessary extensions installed.
A quick rundown of how the deployment works.
The docker container is downloaded. The entry point is called and a script is executed that first using just plain PHP connects to the MySQL server and creates the needed database. Then the script uses server variables sent by AWS to the container to build the “…/app/config/local.php” file. Then the script runs “cache:clear --env=prod --no-warmup”. Then the script runs our custom plugin which drops any exiting tables, recreates the schema, populates the tables with mautic’s DataFixtures it runs on install, and then runs a few of our own DataFixtures that creates a Manager and a Super Admin as well as auto generates landing pages for the themes provided by my client. That plugin executes fine with no error, and I’ve ran it on 2.0.1 locally with no problems.
The Problem:
Requests to any URL result in a redirect (301) loop. I turned on debug mode and the error log is filled with this
Matched route “login”. {“route_parameters”:{"_controller":“Symfony\Bundle\FrameworkBundle\Controller\RedirectController::urlRedirectAction”,“path”:"/s/login",“permanent”:true,“scheme”:“https”,“httpPort”:80,“httpsPort”:443,"_route":“login”}
And that’s it. No other information on why Mautic may be needing to redirect over and over. No further errors in Apache or Nginx’s logs.
If someone could at least point me in a direction.
We’ve flushed cache a billion times. Removed the .htaccess file all together. Restarted apache, nginx, etc. Rebuilt the server. No errors occur during deployment that would lead me to believe that the scripts are causing problems.
I’m not even sure where to start explaining this bug, because it has a lot of moving parts. But I’ll give it a shot.
Background information:
We’re running mautic 2.0.1 in a Docker container on an Elastic Beanstalk server on AWS. Requests are forced to be HTTPS (which works), but all requests come to the Docker container on port 80. A load balancer receives the request on 443, and forwards into the Nginx server on port 80 which proxies the request to the Docker container on port 80.
Also, this was working yesterday before I added some new themes to mautic, and since then has stopped working. But I know this really isn’t all that helpful. And rolling back the changes, while possible, doesn’t help because all the changes were just to add in 2 new themes to the deployment.
The Docker container itself is Apache 2.4 and PHP 5.6 and has all of the necessary extensions installed.
A quick rundown of how the deployment works.
The docker container is downloaded. The entry point is called and a script is executed that first using just plain PHP connects to the MySQL server and creates the needed database. Then the script uses server variables sent by AWS to the container to build the “…/app/config/local.php” file. Then the script runs “cache:clear --env=prod --no-warmup”. Then the script runs our custom plugin which drops any exiting tables, recreates the schema, populates the tables with mautic’s DataFixtures it runs on install, and then runs a few of our own DataFixtures that creates a Manager and a Super Admin as well as auto generates landing pages for the themes provided by my client. That plugin executes fine with no error, and I’ve ran it on 2.0.1 locally with no problems.
The Problem:
Requests to any URL result in a redirect (301) loop. I turned on debug mode and the error log is filled with this
Matched route “login”. {“route_parameters”:{"_controller":“Symfony\Bundle\FrameworkBundle\Controller\RedirectController::urlRedirectAction”,“path”:"/s/login",“permanent”:true,“scheme”:“https”,“httpPort”:80,“httpsPort”:443,"_route":“login”}
And that’s it. No other information on why Mautic may be needing to redirect over and over. No further errors in Apache or Nginx’s logs.
If someone could at least point me in a direction.
We’ve flushed cache a billion times. Removed the .htaccess file all together. Restarted apache, nginx, etc. Rebuilt the server. No errors occur during deployment that would lead me to believe that the scripts are causing problems.
I’ve dealt with this exact issue before on Drupal sites (unrelated to Mautic).
There are a ton of moving pieces that I’m going to cover, so if I’m wrong or my assumptions are off, please correct me and I’ll attack the problem again.
It has to do with the fact that the traffic is coming over port 80 convinces the apache/.htaccess that it is not SSL (even though it is) so it loops it back around to port 443 of the LB, which sends it in as port 80 to the instance, and so forth and so on.
My guess as to why it was functioning before may be related to the cache not having been cleared recently, or the base URL of Mautic having been set to http or https in such a way that the .htaccess redirect never really got triggered (so the bug existed there all along but wasn’t firing off).
The typical .htaccess approach won’t work because it will never think that SSL is on:
RewriteCond %{HTTPS} !=on
However, the LB does send through a X-Forwarded-Proto that you can look for instead:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
And then redirect traffic:
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
There are some other nuances such as multiple SSL config reinforcements… if you removed the .htaccess completely, then there is a deeper Apache config issue (namely that you aren’t allowing config overrides at the folder level). If you type something incorrect like “test” at the beginning of the .htaccess file, does it bring the site down entirely? If it doesn’t, let me know.
Feel free to PM me as well.
As a side note, I use the AWS Bitnami image off of the marketplace… it works like a champ 
… (although some configuration is needed to make it work like a champ)
Hey Caleb,
All of what you suggested we already did, but I just wanted to let you know we got a solution and added
SetEnvIf x-forwarded-proto https HTTPS=on
Just under our 301 redirect for HTTPS and this seems to have fixed the redirect issue.
Thanks a lot. I had the same problem with my mautic on AWS(+ELB) and this solution resolve the loop problem.