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.
Related
I have created a virtual server say aaa.com but when I access the site (via editing my hosts file on Windows 7, cos I have a live aaa.com running on the Internet), it brings me to my other virtual server's site I have, like bbb.com
Why is that? I don't have any redirection running. Not in my script files (like html or php) and no redirection set under "Server Configurations" -> "Website Redirects" and none at "Services" -> "Click Configure Website" -> "Aliases and Redirects." The only script files I have are fresh new WordPress installation files (under home/aaa/public_html).
How do I fix this?
Mullazman is right (thanks!). I have just had this problem after enabling the SSL on the domain A. Then, all the domains in the same installation were pointing to A.
I fixed it by editing the file located in /etc/apache2/sites-enabled/A.conf and changing the first line:
Wrong line -> <VirtualHost A.B.C.D:80>
Correct line -> <VirtualHost *:80>
Had the same issue. For anyone interested it's because I had at the header of my sites-enables/aaa.com.conf which was picking up all requests and send them to the first host.
Change it to and it started directing traffic to the correct virtual hosts.
It was triggered when I enabled SSL on aaa.com, it for some reason re-wrote the config file to use IP based filtering not domain name
Try to delete browser cache with CTRL+F5,
then try again. If that doesn't help, check virtualhost configuration files -maybe there lies the problem.
The solution I found
I had the same problem ...
And I ended up with a lot of doubts ...
And I searched for a SOLUTION for this case, I hope to help ...
1 - Should the BIND have an external or internal IP in the domain? I use only one IP for all servers, and in BIND all domains are with external IP. (The question is whether it should be external or internal IP).
R = Yes, you must configure the internal IP in Virtualmin, prefer to edit the file. Only in localhost you should have 127.0.0.1
2 - Would NGINX have any configuration? How to remove IP and just put (listen *: 80) instead of (listen 288.218.198.981:80)
R = This configuration was changed but then I had problems with DNS and I returned to use the INTERNAL IP (not the localhost) ... Normally this IP starts as: 10.1xx.xx.xx
But which configuration would work in general?
Restart these steps ...
If you still have an error ...
Back up ... And in Virtualmin settings ...
Edit Virtual Server >> Activate Features >>
Uncheck NGINX, BIND, NGINX SSL.
He will ask for confirmation and click to confirm.
After this process is completed, return to the same option and reschedule ...
This will make it delete the old ones and put a new one.
(This works great for those who changed hosting and has old settings).
If you are importing a backup. Do not select the DNS and NGINX option ...
One tip is to create Virtual Server {your domain / site} First of all ...
And only then only import directories and databases ...
So you will not have problems with DNS and wrong redirects ...
Update
This also occurs when the SSL certificate is not issued correctly.
Folder permissions are incorrect.
Chmod 0755 folders
0644 Files
SOLUTION!!!
Cheap workaround let us say our domain is domain.xyz
Under the BindDNS Master Zone for domain.xyz create a cname record I believe it is listed in webmin as Name Alias and name it 000.domain.xyz
Under apache create a virtual server with the name 000.domain.xyz and make sure it has the same directory as domain.xyz
After this is done you are golden all your websites will come up as they should!
Is it proper well maybe not.
Does it work well like a charm of course otherwise I wouldn't be sharing for some reason the way the severs are listed it defaults to the first on the list well that'll fix that there should be a method of pinning the servers or doing something to prevent such a thing from happening what a pain in the rear I spent a full day dumbfounded thinking what in the world is going on I am losing my touch.
If this helps give a like if its wrong apologies all I know is that it works.
Read the thread.
Many folks claim this is an SSL thing.
Zero people have eluded to the true method of fixing it or the proper directions to do so or if they did I'm too blind to see it.
The guy below me commenting hrmmm... Yeah browser caches for my website didn't exist on my devices I tried them on to verify that was not the problem. But yes this is a typical problem with a lot of things indeed. It is the only reason I have several browsers on my PC actually for that reason. For a while there there were pages that chrome would function with that IE wouldn't or Firefox would best them both. Not to mention cache is always a pita its always usually one of my steps in troubleshooting any issues with web pages. I'll even try openDNS or other DNS servers.
But holy cats I can't believe how fast DNS just updates once you got things set it makes me wonder if there is a lot of fudge in propigation when you purchase hosting being "24 -48 hours" I think there is a lot of fudge in those numbers after my experiences trying to figure out what was causing the issue here. Some servers struggle yes but for the most part it was pretty instant for me.
In my case it happened after creating SSL certificate, I forgot to do:
Edit Virtual Server -> Enable Apache SSL Website
I've just installed Sylius to test it for possible production use and integrated Paypal through the payum-gateway.
I'm running Sylius with the included webserver on 127.0.0.1:8080 through a nginx reverse SSL proxy for security reasons and so that it is accessible through a regular URI.
After the PayPal-Payment, I'm forwarded back to the page as it should but instead of the origin-page it sends to 127.0.0.1:8080.
The "Show Shop"-link from the admin-menu did this as well until I changed the server name in the "channel settings".
I figured I have to set the public hostname somewhere else, too, but I cannot figure out where I have to do so.
Grepping for '127.0.0.1' yields a lot of results. For example vendor/sensio/distribution-bundle/Resources/skeleton/web/config.php, but that doesn't seem to be the right place.
I don't know the answer to the original question so I won't delete it in case someone else wants to answer.
I solved this specific problem by not using nginx as a proxy but as the webserver itself and deacitivating the webserver that is shipped with Sylius.
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,
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
We are putting up a company blog at companyname.com/blog but for now the blog is a Wordpress installation that lives on a different server (blog.companyname.com).
The intention is to have the blog and web site both on the same server in a month or two, but that leaves a problem in the interim.
At the moment I am using mod_rewrite to do the following:
http://companyname.com/blog/article-name redirects to http://blog.companyname.com/article-name
Can I somehow keep the address bar displaying companyname.com/blog even though the content is coming from the latter blog.companyname.com?
I can see how to do this if it is on the same server and vhost, but not across a different server?
Thanks
Rather than using mod_rewrite, you could use mod_proxy to set up a reverse proxy on companyname.com, so that requests to http://companyname.com/blog/article-name are proxied (rather than redirected) to http://blog.companyname.com/article-name.
Here are more instructions and examples.
There is functionality with ZoneEdit called webforwards which could probably do this and hide what you are actually doing (unless someone looked into it).
The only thing that mod_rewrite can do is send HTTP header redirects, and those redirects (across servers) always result in the browser address bar reflecting the reality.
You should instead consider writing a 404 script that 'reflects' the blog. This would essentially be a transparent proxy, and many are already written.
The script would find if the requested page (that was 404'd) started with http://mycompany.com/blog/ . If it did, it would download and then send onto the client the blog page and associated files (probably caching them as well).
So requesting http://mycompany.com/blog/article_xyz would cause the 404 script to download and send http://blog.companyname.com/article_xyz.
It's probably more work than it's worth, but you might be able to design a simple enough 404 script that it's worthwhile.
-Adam