How to solve prestashop infinite redirection loop under ssl? - ssl

Don't know, maybe someone had the same problem before..
I've got a correctly configured ssl certificate in my server.
If I activate prestashop ssl mode, then several pages generate an infinite redirection loop warning....
I really can't figure out why..
One thing I can say, is that in backoffice, clicking on the ssl acivation link, it does not activate it: it stays, silently, no rerrors, nothing.
So to activate ssl I had to manually change the relevant config variable on the DB.
This could maybe be a symptom of something wrong on the server?
Anyone had the same problem?
Thank you

Apart from upgrading to v1.6.0.11, the solution was to add SetEnv HTTPS On at the very top of .htaccess. That's because several prestashop functions rely on $_SERVER['HTTPS'] and/or $_SERVER['SSL'] vars to guess the urls. One of the most notable functions using them and itself used by many others is Tools::usingSecureMode(). Simply those vars weren't visible before adding SetEnv HTTPS On.
Anyway, this is not to be considered a universal solution, because for example in my local MAMP installation I didn't have the same issue: just worked. I only needed the tweak for the remote server.
Beside this, also note that in backoffice, unde url/seo prefs, I disabled the apache multiviews.
Hope it helps

Related

How can I use an .htaccess file in Nginx?

I am currently migrating my website from Apache to nginx, but my .htaccess file is not working. My website is inside the /usr/share/nginx/html/mywebsite folder. How can I use .htaccess in my nginx server?
This is my .htaccess file:
RewriteEngine on
RewriteRule video/watch/([a-zA-Z0-9_#$*-]+)/?$ "videos-single.php?id=$1" [NC]
Nginx doesn't support .htaccess (see here: "You can’t do this. You shouldn’t. If you need .htaccess, you’re probably doing it wrong.").
You've two choices (as I know):
import your .htaccess to nginx.conf (maybe the htaccess to nginx converter helps you)
use authd-htpasswd (I didn't try it)
Disclosure: I am the author of htaccess for nginx, which is now open source software.
Over the past years, I created a plugin which implements htaccess behaviour into nginx, especially things like RewriteRule, Allow and Deny, which can be crucial for web security. The plugin is used in my own productive environments without a problem.
I totally share the point of efficiency and speed in nginx, and why they didn't implement htaccess.
However, think about it. You cannot make it worse if you're using nginx plus htaccess. You still keep the great performance of nginx, plus you can drive your legacy appliances effortlessly on one webserver.
This is not supported officially in nginx. If you need this kind of functionality you will need to use Apache or some other http server which supports it.
That said, the official nginx reasoning is flawed because it conflates what users want to do with the way it is done. For example, nginx could easily check the directories only every 10 seconds / minute or so, or it could use inotify and similar mechanisms. This would avoid the need to check it on every request... But knowing that doesn't help you. :)
You could get around this limitation by writing a script that would wait for nginx config files to appear and then copy them to /etc/nginx/conf.d/. However there might be some security implications - as there is no native support for .htaccess in nginx, there is also no support for limiting allowed configuration directives in config files. YMMV.
Using the config file is one option, but the cool thing about the .htaccess file is that it provided a way for a web developer to have some control over server settings without having root access to the server. There doesn't seem to be anything like this on nginx which is a real bummer.
I understand how the way it's setup on apache slows down response times, but hoped there could be an nginx way to do the same thing without the performance hit... At least a way to do rewrites with regex on urls if nothing else.
"Is there no nginx way to do bulk redirects using regular expressions that doesn't slow down response times."
Just edit your database with myphpmyadmin.
Open myphpmyadmin select your database then find your "yourprefix_Posts" table.
Open it then click the "Search" tab, then "Find and Replace".
Select "post_content" in the dropdown
In the "Find" field, type URL you want to change: "website.com/oldURL".
In the "Replace" field, type the new URL: "website.com/newURL".
(To use regular expression, tick the "Regular Expression" box.)
NOTE: You can test this out by simply leaving the "Replace" field blank.
ALWAYS BACKUP database before making changes. This might sound scary but its really not. Its super simple and can be used to quickly replace just about anbything.

getPageLink() and https

So I've recently implemented and activated SSL certification on my webshop. Now I need to change all the links on it to https:// from http://
There are a few hardcoded links on the site that I'm in the process of changing but most of the links are generated by a function that fetches the url from the PS database and I've managed to figure out that you add "true" value as argument and it will fetch the https url.
The thing is that there are a lot of diff. modules and it would take a lot of time to do such thing. So I thought there might be an easier way to do this? Some kind of configuration that will add "true" value as argument for all getPageLink() functions.
The SSL is working fine. The only thing Firefox, Chrome etc are complaining on is that some elements are not https. Any help would be appritiated.
Edit : I figured there has to be some kind of global variable that respresents the domain name. So I went to the database and found PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL. From what I've been able to figure out is that PS only apply SSL on the order and account pages. But I need it for all pages. so I changed the value for PS_SHOP_DOMAIN to https://domain.com but this did not make any difference. Am I on the right path?
Did you enable SSL here:
Preferences -> General -> Enable SSL
Regards,

Necessary Apache Redirect to handle absolute svn:external references after a url change

So our Subversion server changed. And with it came a necessary url change, from https://hostname of the previous machine, to a more apt https://svn.
Problem is, a lot of the externals use the absolute https://hostname/blah/blah/blah rather than ^/blah/blah/blah. And this has obviously led to a lot of failures.
To prevent the headache of change possibly hundreds of externals one checkout at a time, I've been asked to figure out a way to utilize http redirects to allow the externals to stay as they are for now.
I've got this simple rule in the httpd.conf of the old server, which is still being used for other http services.
Redirect /repo/ https://svn/repo/
And that works fine for the web browsing of our repositories. But it doesn't work for TortoiseSVN, I just get "Repository moved temporarily to 'https://svn/repo'; please relocate". And on linux I just get "Unable to connect to a repository at URL 'https://old hostname/repo/blah/blah'".
Is this possible at all? I hope it is and I just need a different form of redirect.
Nevermind. I'm too new to this. I had to change 'Redirect' to 'Redirect 301'.
Probably should have been obvious. But it works now.

Opencart links not https?

I have purchased an ssl certificate, I have enabled the SSL setting in the settings and I have changed both config files to go to https but when I visit http://bit.ly/TCkEBv the first page is https the rest are not. How can I fix this?
I realize this is an old thread but considering the recent google SSL-everywhere indexing changes, i figured it was relevant. The following example will make OC use https in all links. You have to change 3 characters in system/library/url.php. They deleted this on the forums which is understandable, but we have ran it for a week of production traffic on mixed SSL multistores with no issues.
WARNING: Your mods may be different - run through them all in a test after enabling this...especially any redirect managers. Here is the tweak for 1.5.6:
Open store/system/library/url.php and find $url = $this->url; in an IF statement somewhere near line 18. Change it to $url = $this->ssl; and there ya go.
PS: Also there is a vastly untested method to send the https-preferred as a header using $response->addHeader('Strict-Transport-Security: max-age=31536000'); but i am unsure of best spot to put it besides index.php. Also, although it works in test, unsure of all-server implications. Header controller seems logical, but not all OC areas use header controller :). Experiment with best placement for that....just dont do it in the $url replicator even if it seems like it works.
As per the forum thread, this is not actually a bug just the way that the cart is set up - that is most pages are not set as HTTPS and will revert to HTTP once you click on a non HTTPS link
Let's say you have a Domain called example.org
Instead of changing the code, in Apache, you could do this...
In addition to your Domain-SSL.conf, you can copy that configuration to Domain.conf and edit it to use port 80 instead of 443
Then, add this line in the Server definitions at the top, right before DirectoryIndex...
Redirect / https://example.org
This will simply redirect every request back to the SSL configuration, adding the https:// in front of every link. No code changes required to OC.
This has been working on my busy production server for several years without a single problem.

Enabling SSL in Typo3

Hi Typo3 users out there,
I was wondering if Typo3 has native SSL support. The SSL certificate is allready installed on the server, but somehow I can't figure out how to enable SSL for all pages. Does anyone know how to achieve this?
Thank you in advance
Dennis
I think you need to do two things:
Use your vhost-configuration or .htaccess to redirect everything to a https-site. Here is how to do that: Force SSL/https using .htaccess and mod_rewrite
Configure TYPO3 to generate https-urls instead of http ones. You can do that by setting config.baseURL or config.absRefPrefix accordingly in TYPOScript. The latter setting is preferred, as it prevents some compatibility issues.
I hope that is everything that is needed, otherwiese please comment.