if you work with SameSite cookie attribute and set it to strict and the server return a http error code like 404 or 500 an error message is displayed in chrome. So far so good. But if then the user refresh the page (F5 or reload button) while the 404 error message is displayed the cookies are not send with the GET request.
Is this the normal behavior? Tested it with FF 71 and the strict cookies are sent.
Related
When visiting my website that is protected w/ HTTP basic authentication in either Chrome or Brave the browser will re-prompt upon each page reload. Visiting the same page in either Firefox or Safari only prompts the first time then the credentials are "remembered" for the remainder of the session.
In my response I'm sending back the following header:
WWW-Authenticate: Basic realm="website"
How can I get Chrome / Brave to "remember" the HTTP basic auth credentials for the duration of a session?
I'm trying to figure out how to get web torrent to play a video, but I'm getting some weird errors. Here is a pastebin: https://pastebin.com/raw/3wp5F8Fh
And here is a live version: https://41182065-e8d9-40b1-8dd9-9433b402bce9.htmlpasta.com/
When we go to the chrome console, we get this:
Mixed Content: The page at 'https://41182065-e8d9-40b1-8dd9-9433b402bce9.htmlpasta.com/' was loaded over HTTPS, but requested an insecure script 'http://momentjs.com/downloads/moment.min.js'. This request has been blocked; the content must be served over HTTPS.
/favicon.ico:1 Failed to load resource: the server responded with a status of 404 ()
(index):1 Access to XMLHttpRequest at 'https://nyaa.si/download/941788.torrent' from origin 'https://41182065-e8d9-40b1-8dd9-9433b402bce9.htmlpasta.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
webtorrent.min.js:4 Uncaught Error: Error downloading torrent: XHR error
at webtorrent.min.js:5
at t.exports.<anonymous> (webtorrent.min.js:7)
at t.exports.t (webtorrent.min.js:5)
at t.exports.r.emit (webtorrent.min.js:4)
at XMLHttpRequest.c.onerror (webtorrent.min.js:7)
The explanation is in the error message, but in short: your browser has blocked the request because you're using AJAX to communicate with a remote server and that server isn't sending the appropriate 'Access-Control-Allow-Origin' header.
The reason such requests are blocked is to protect you from malicious scripts - if you're logged in to website A and have access to some private data, then website B shouldn't be able to trigger an AJAX request to access that data unless A trusts B.
The general term for this kind of access is 'Cross Origin Resource Sharing' or 'CORS' - for more information, Mozilla have a nice summary here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
If you have control of the remote server then responding with the appropriate header will allow the request to go through (although note that some browsers such as Safari will still block cookies from the remote server because this technique can be used for tracking).
The following has been seen in Chrome's console (anonymized domains, boldface has been added):
> somesite.ourdomain.org:44301/api/v1.0/AppCache/AdministrationStatusApi:1 GET https://devesaapi.abim.org:44301/api/v1.0/AppCache/AdministrationStatusApi 503 (Service Unavailable)
> esa:1 Access to XMLHttpRequest at 'https://somesite.ourdomain.org:44301/api/v1.0/AppCache/AdministrationStatusApi' from origin 'https://othersite.ourdomain.org:44301' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource
The true reason for the 503 is that one of the load-balanced nodes was not responding correctly to the load balancer. However, Chrome decided that since the 503 response didn't have an Access-Control-Allow-Origin header on this cross-site request, it should complain about CORS.
The reason this is bad is because it misled our developers and wasted some time hunting down a CORS problem that wasn't really there.
Is Chrome really doing the right thing by reporting that this request, which returned 503, is a CORS violation?? What do other browsers do?
Google Chrome stable Version 72.0.3626.109 (Official Build) (64-bit) on Windows 10
EDIT: At least one other developer blogger agrees with me.
I am currently doing some debugging on my website which involves calling the facebook API. I've installed dnsmasq to work with my mac os X to redirect all request to facebook.com to 127.0.0.1
This is my entry in dnsmasq.conf:
address=/facebook.com/127.0.0.1
I also have /etc/resolver/com with nameserver 127.0.0.1
When I turn dnsmasq on, visiting facebook.com will result in a PAGE NOT FOUND error in chrome. This shows that my dnsmasq is working.
However, I noticed that chrome will redirect http://www.facebook.com to https://www.facebook.com due to HSTS. I went on to chrome://net-internals#hsts to delete facebook.com's entry.
The strange thing is, when I am debugging, I see that facebook.com is indeed returning 307 redirects for http://www.facebook.com (See image)
This is very strange because the domain facebook.com is currently resolved to be 127.0.0.1 on my computer! Furthermore, when I dig more into the request, I do see that the request is valid:
Where is this 307 redirect coming from if facebook.com is unresolvable?
307 is an internal browser based redirect for HTTP Strict Transport Security (HSTS). It does not come from the server - it's a fake response created by the browser.
On OS X I have a simple html page which I open using a file:///... url. This page contains javascript which attempts to load a http://... resource.
This works using Safari, but it doesn't work under Firefox or Chrome.
The error message I get from those browsers are:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://whatever/etc. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
Is there to get the page to work under Firefox and Chrome?