Jump to content

pinterface

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by pinterface

  1. The three lines I posted (and have duplicated below) appear to work for me, in my environment, yes. But as I've mentioned, I don't know if settings.inc.php is modified during the upgrade process, so I'd be hesitant to consider it a permanent fix. if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])) { $_SERVER['HTTPS'] = 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ? 'on' : 'off'; }
  2. Alas, I am apparently incapable of explaining the problem in a way which puts us at an even understanding. But certainly modifying Tools::file_get_contents() is not going to help Tools::usingSecureMode() return the correct value. I appreciate the effort, though. Maybe not entirely unique (this post was almost certainly the same issue, for instance), but yeah, it's not something you're going to run into on generic el-cheapo webhost 37. And I did post a workaround , though I still don't know if where I put it (settings.inc.php) is upgrade-safe.
  3. Well that does involve proxying, yes, but unfortunately that's for an entirely different thing (Prestashop talking to other servers, not browsers talking to Prestashop). My problem is a "reverse proxy" scenario. Apologies for any confusion caused by my loose terminology earlier. Basically, the user's browser connects to a server (nginx, lighttpd, whatever) which handles the SSL, then forwards the request on to apache as a regular (non-SSL) HTTP request with some additional headers such as X-Forwarded-Proto and X-Forwarded-For, so one can distinguish betwixt client requests. Thus, $_SERVER['HTTPS'] is never "on" because apache never deals with the SSL, and Prestashop never checks the de-facto standard header added by the reverse proxy to tell it what protocol is being used for the client connection, so it never detects SSL is in use for the client connection. Since Prestashop doesn't appear to have native support for this mode of operation, I can fake it with a bit of smoke and mirrors, but I'm not familiar enough with the software yet to know what file (if any) is both going to be used on every request and would be safe to splice in a fix without worrying about being overwritten on upgrades. (E.g., is config/settings.inc.php safe, or is that a candidate for being rewritten on upgrades?)
  4. No worries on the prelim questions. I appreciate the help. Forcing SSL on without having a way for it to detect SSL is in use just results in infinite redirects on pages which are forced to SSL (e.g., /en/order-history), presumably because without detecting the SSL proxy it mistakenly thinks the end user is not using SSL, and so redirects to HTTPS, where it doesn't detect SSL and ... well, you get the idea. If I add in my little snippet to munge $_SERVER['HTTPS'] it appears to function correctly, but that's not really a permanent solution without some place I can put it that'll survive upgrades.
  5. At that point, I get taken to the same page, but via SSL, and it continues to say "Please click here to use HTTPS protocol before enabling SSL.". Yes. The proxy works fine, I'm just not seeing anything in Prestashop's code which attempts to detect an SSL proxy in use, and I'm not sure where a safe, upgrade-surviving place to put a snippet like the following to fake it out would be: if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])) { $_SERVER['HTTPS'] = 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ? 'on' : 'off'; }
  6. Thanks Bill, but I already /have/ an SSL proxy set up. My problem is that Prestashop doesn't seem to attempt to detect this case (e.g., by checking X-Forwarded-Proto), and I'm not sure how to explicitly override its incorrect detection in a way that will survive upgrades, etc.
  7. I'm experimenting with prestashop (1.5.6.0, according to _PS_VERSION_) and have a fairly typical setup of apache behind an SSL proxy. This works, in as much as I can visit an https page, however, Prestashop fails to detect that an SSL proxy is in use and thinks everything is on HTTP, and links everything to http URLs (why it isn't simply using relative URLs is beyond me, but that's beside the point), which of course means SSL never really sticks around. E.g., I can't enable it inside the admin interface, and even if I could it wouldn't recognize users were using SSL either, and would constantly be sending them back to non-SSL pages. So the question is how do I get it to detect SSL with a proxy in front? I'm hesitant to just modify Tools::usingSecureMode() (and possibly other functions which may need it) since it's been my experience that modifying central files tends to break upgrades when the upgrade overwrites the file and then dies halfway through because it no longer detects the thing it was looking for, so I was hoping there's some way I'm missing. Some relevant data from $_SERVER: Array ( [HTTP_X_FORWARDED_FOR] => 10.122.69.49 [HTTP_X_FORWARDED_PROTO] => https [PATH] => /usr/local/bin:/usr/bin:/bin [sERVER_SOFTWARE] => Apache/2.2.22 (Debian) [sERVER_ADDR] => 127.0.0.1 [sERVER_PORT] => 80 [sERVER_PROTOCOL] => HTTP/1.0 [REQUEST_METHOD] => GET ) Thanks!
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More