I have disabled SSL in all pages at Prestashop and now there is this error (i do not enter https and it puts https):
I tried deleting htaccess and regenerating it, but it didn't work.
This is the Prestashop configuration:
Which is the solution?
EDIT: My configuration of SSL at Prestashop configuration tab
I'm not familiar with Prestashop, however the issue is that at the time being the site enforces the HTTPS. In fact, the non-HTTPS version redirects to the HTTPS, there may be other redirects (that are not enabled now as I can access the redirect target) that may have caused the loop.
➜ ~ curl -I http://runvaspain.com
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Sun, 24 Jan 2016 10:44:09 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Cache-Control: no-cache
Location: https://runvaspain.com/
X-Powered-By: PleskLin
Vary: Accept-Encoding
Strict-Transport-Security: max-age=15768000;includeSubDomains
Moreover, it looks like the site is setting the HSTS header
Strict-Transport-Security: max-age=15768000;includeSubDomains
This header is ignored when served via HTTP, however I suppose this was also served via HTTPS, therefore your browser have probably saved the configuration and it's enforcing the HTTPS locally (given that's what the HSTS is about).
You'll have to manually remove the strict transport configuration for the domain in your browser. However, please note that any user that previously accessed your site will have such setting, therefore they will be forced to use HTTPS for the main site and all subdomains for 6 months (as this is the policy you previous set).
Also note that, since you previously sent that header, HTTPS will be enabled for the entire site (and also subdomains), it's not possible to enable it on a single page (at least for the users who visited it before). The best thing to do is to turn HTTPS on again for the entire site.
To solve the first issue (the redirect to HTTPS) you should contact the Prestashop service. However, please note it will be almost irrelevant if the HSTS header was previously sent.
The http version of the website ( http://runvaspain.com ) send a 301 redirect to the https version.
The https version of the website ( https://runvaspain.com ) use the HSTS header with a max-age of 6 month
That's mean that anyone who visited the website is forced to visit the HTTPS version
It's a security feature added by HSTS.
You have two solutions:
Reactivate the https version (It's my advice, as https add a significant security to your visitors)
Redirect the https to http AND modify the HSTS header (probably in your apache configuration) to send a max-age of 0. You MUST send it for at least 6 month, you can't just remove it! Sending a max-age on 0 indicate to visitors who already visited the website to forget the HSTS settings. If you just remove it, those visitors will not be able to visits the webpage for the next six months !
in prestashop after configure with ssl, admin dashboard works. but public sites doesn't work anymore. because you have to enable SSL for front pages, using admin dashboard like bellow.
Enable SSL - yes
Enable SSL on all pages - yes
change your shop parameters like this
refer the image
I think Chrome just cached the URL. Happens to me all the time during development.
Try
List item
Click Menu (three dots or whatever icon is it now in Chrome in the upper right corner)
Hover over More tools then Developer tools
Click Network tab
Click Disable cache checkbox
Related
I want to remove a cache-control header from URL's with a specific query params. e.g. when the query paramater ajax=1 is present.
e.g
www.domain.com?p=3&scroll=1&ajax=1&scroll=1
These are getting cached by chrome browsers for longer than I would like and I would like to stop that in this specific case. I have tried with .htaccess which works for static files however not in action on the URL's mentioned above.
RewriteEngine on
RewriteCond %{QUERY_STRING} (^|&)ajax=1(&|$)
Header unset "Cache-Control"
I could use a cache buster in the next website release but difficult in production and worried it would unnecessarily cache lots of files in user browsers so would rather achieve server side.
My server has Cloudflare then NGINX terminating SSL to Varnish then Apache with a Magento 2 instance running on there. So thinking i could possibly achieve this with NGINX or Varnish configs, or even Cloudflare. I however couldn't seem to find a way to achieve this with page rules in Cloudflare, or could not find examples for Varnish or Nginx.
I'm assuming you don't want to cache when ajax=1 is part of your URL params?
You can do this in Varnish using the following VCL snippet:
sub vcl_backend_response {
if(bereq.url ~ "\?([^&]*&)*ajax=1(&[^&]*)*$") {
set beresp.http.cache-control = "private, no-cache, no-store";
set beresp.uncacheable = true;
}
}
This snippet will make sure Varnish doesn't cache responses where the URL contains an ajax=1 URL parameter. It will also make sure any caching proxy that sits in front will not cache, because of the Cache-Control: private, no-cache, no-store.
Is this what you're looking for?
I recently saw a few malicious domains including my website pages.
I initially suspected of iframe inclusion, but I already had Header always set X-Frame-Options SAMEORIGIN configured in my httpd.conf.
Other ideas were about malware Javascript including remote pages in the DOM, or even external DNS pointing to my server IP (however, I have name-based virtual hosting on). None of them have been proved.
Investigating on remote domain and looking at apache logs showed us the reality: the malicious remote server made http requests to us, for each request it received, then sent back the result to its clients, actually "mirroring" our website!
I lack ideas on how to stop it. So I blocked its User-Agent completely, via apache conf: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Hope I explained myself. Is there a smarter way to stop such a bad behavior from other domains like them, in the future?
I have a strange problem which I can't identify the cause of.
There are two servers which host two different sites. Both sites are PHP-based apps.
Server 1 (Ubuntu)
https://app.site1.com
Server has SSL enabled for this site. This site works fine.
Server 2 (Red Hat)
http://app.site2.com
Server does not have SSL enabled for this site.
Here's what happens:
If I access site 2 on http:// it works fine.
If I access site 2 on https:// it redirects to site 1 on the other server.
Now obviously there is something telling this subdomain to go to the other site when served via SSL.
What I have checked:
All virtual hosts on both servers
All DNS records on both servers
All Site 2 website code
Site 2 .htaccess files
Using uncached browsers
There is NOTHING on either of the servers, that I can find, telling site 2 to redirect to site 1, only on HTTPS. Now obviously I don't expect anybody to find the problem directly because you can't see my entire server configuration, but I am looking for suggestions as to where else this redirect could come from.
I could understand this if you had site1 and site2 hosted on the same server.
Basically if you have no config set up for a second vhost on https (port 443) then Apache will fall back to first vhost by default.
So if both sites were in same Apache config then that might be it. But you say they are not. Are you sure you are not serving both sites from the same server (perhaps with a copy in the other server)? Are the IP addresses the same? Are there any load balancers or CDN infrastructure in front of both servers?
Also you say "If I access site 2 on https:// it redirects to site 1 on the other server." Can you explain more about what happens here? If you go to site 2 and do not have https set up then how can this even respond to this request? What certificate is being presented to that initial request (i.e. before the redirect)? Is it the site1 certificate? And if so then do you get a certificate error in the browser (since its presenting the wrong certificate for the site you requested) that you have to click through before you get redirected? Or is the cert valid for both sites?
You can also use this openssl command to see what the server returns (and in particular which certificate it returns):
openssl s_client -connect app.site2.com:443
It would also be handy to look at the browsers developer tools and see how exactly the redirect is happening. In Chrome press F12, go to Network tab, click on preserve log and then go to https://app.site2.com/. What is the first request? Is it a 301 or 302 (i.e. Server side redirect)? Or if it's a 200 followed by the https://app.site1.com/ then some piece of JavaScript must have caused the redirect.
Once you have answered those questions it may be possible to provide further guidance.
I have an Apache server that I'm attempting to send requests over HTTPS to, but I've been struggling to get past cross origin issues as well as issues using SSL.
I'm not exactly sure where the problem lies, as I seem to be getting different responses back from the web consoles (testing with Firefox + Chrome) concerning the failed request. In Chrome, I simply see that the request that is sent as a POST is changed to OPTIONS and notes that it failed without much else. In Firefox, I see the following two issues:
In the console, the request says it fails due to CORS:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://123.456.789.001. This can be fixed by moving the resource to the same domain or enabling CORS.
However, inspecting the failed request in the network tab shows the following issue about the certificate:
123.456.789.001 uses an invalid security certificate. The certificate is not trusted because it is self-signed. (Error code: sec_error_unknown_issuer)
After digging, I'm having issues determining what is actually causing the request to fail - is it because my CORS rules are not setup properly? Or is it because I'm attempting to send requests to a server that is using a self signed certificate and therefore not being trusted by my request/browser?
I believe CORS is setup properly on my end, here are the contents of the files I'm using to enable CORS:
Crossdomain.xml
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>
.htaccess:
# Always set these headers.
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token, Access-Control-Allow-Origin, X-Frame-Options"
# Added a rewrite to respond with a 200 SUCCESS on every OPTIONS request.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
Obviously these settings aren't great for production, but after spending hours trying to pinpoint the issue, I went with some examples that were the least restrictive in terms of enabling CORS hoping I'd see the requests go through and then go back and edit them properly. However, I still see the Cross Origin errors in the console with these changes uploaded to the Apache server (and server restarted after files changed).
So is there anyway to tell if CORS or the self-signed certificate is causing the issue? I didn't necessarily want to go ahead and purchase a SSL certificate at this time since I'm still in development, and the site I'm using to host the content is forced to https, so I can't pass the requests over http.
I would appreciate some help to understand what is going on: both Firefox and Chrome are failing to load my non-SSL website, say subdomain.example.com, with the following SSL errors (both on ubuntu 14.04 i386):
FF30: ssl_error_rx_record_too_long
Chrome 35: ERR_SSL_PROTOCOL_ERROR
This started to occur after I set (and follow) a redirect (302) to SSL on the parent domain, say http://example.com to https://example.com. It gets back to normal after a full cache clean on the browser. But as soon as I access the parent domain I get the problem on the subdomain.
I have never entered the subdomain URL with the "https://" scheme prefix. I don't usually type any prefix and it is happening even if I explicitly prefix with "http://". And it is not only on the address bar, the same happens for links.
I am very confident that there is nothing wrong with the non-SSL site on the subdomain.
I thought about filling a bug report but it is unlikely this is a bug in both browsers and more likely I am missing something.
It there any rule that if a website on a given domain supports SSL (or redirects http to https), then sites on subdomains are assumed to do as well?
I later found the cause of the SSL errors. But the problem still persists (now the message is connection refused):
Apache web server was configured to listen on both ports 80 and 443, but with no "SSLEngine on" clause. This effectively makes it serve plain HTTP on port 443.
It is worth to mention that this Apache configuration mistake is not that hard to fall into. Actually, in the default Ubuntu configuration (possibly the same for Debian), it is just a matter of enabling/loading the SSL module (and not providing a site configuration that uses SSL).
I have just found the cause. The ssl site on the parent domain is including the following STS response header:
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
That triggers the browser behavior by spec.