Post by eventhorizons » Tue Jun 22, 2021 2:02 pm

My setup is as follows:

webuser -> apache reverse proxy with SSL -> bitnami container with opencart (no SSL)

OpenCart is configured with two stores, "store.domain1.com" and "store.domain2.com"

Both domains are pointed to the reverse proxy, SSL is configured and working.

However, when I hit domain2 it serves up the content from the store at domain1 and all links on the page take me to domain1.

I found a topic from 2017 where someone said we needed to detect the proxy variable instead of the http.
(viewtopic.php?t=173145)

Unfortunately, the code he provided was for OpenCart 1.5!

I looked at the code on my instance but it looks like it has changed so much that it will take a deeper dive to figure it out.

I'm hoping that either 1) someone has already figured this out or the 2) it's supposed to already work and I have simply mis-configured something else.

Thanks!

Newbie

Posts

Joined
Fri Feb 22, 2019 8:02 am

Post by straightlight » Tue Jun 22, 2021 9:40 pm

For OC v3.x releases, it looks like these changes may need to be done into the controller/startup/startup.php file.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by eventhorizons » Sun Jun 27, 2021 12:57 pm

In case it was not clear earlier, the reverse proxy is managing the SSL, so the traffic being passed to the OpenCart instance is only plain http.

However, based on my research, I had set the HTTP_X_FORWARDED_PROTO to "https". My understanding is that this is so that links are properly formed.

I determined that the code in ".../opencart/catalog/controller/startup/startup.php" was defaulting to store ID 0 or "domain1.com".

When I viewed the $_SERVER array I found that [HTTPS]=> 1, which affected how the database was queried.
This caused it to do a hard-coded lookup for an "https://" domain in the database.
Since it was not finding a match, it was defaulting to the default store ID or "domain1.com", even though the hostnames were all present and correct.

The fix was to add the full https URL ("https://store.domain2.com/") to the "SSL URL" field in the the store config for domain2.com.

Not sure why I did not find this fix earlier as I know I had that set at some point, but I was fiddling with different settings so I may have had something else wrong at the same time or I may have not entered it exactly that way.

My Apache Reverse proxy is configured as follows:

Code: Select all

<VirtualHost *:443>
     RequestHeader set X-Forwarded-Proto "https"
     ServerName store.domain2.com

     ProxyPreserveHost On
     # the trailing slash is important!
     ProxyPass / http://192.168.xx.xx/
     ProxyPassReverse / http://192.168.xx.xx/
     ProxyPassReverseCookiePath /store.domain2.com /
     ProxyPassReverseCookieDomain 192.168.xx.xx store.domain2.com

     SSLEngine On
     SSLProxyEngine On
     SSLProtocol all -SSLv2
     SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
     SSLCertificateFile /etc/letsencrypt/live/domain1.com/cert.pem
     SSLCertificateKeyFile /etc/letsencrypt/live/domain1.com/privkey.pem
     SSLCertificateChainFile /etc/letsencrypt/live/domain1.com/fullchain.pem

</VirtualHost>
Note that the SSL certificate is for "domain1. com". I have multiple domains under the same LetsEncrypt certificate so this works perfectly.

Thank you for providing me with the direction that I needed to focus on!

Newbie

Posts

Joined
Fri Feb 22, 2019 8:02 am
Who is online

Users browsing this forum: No registered users and 44 guests