i have one domain (lets name it domain1.com) and another subdomain (lets call it test.domain1.com)
the target cookie name is "login"
if i set cookie in the domain1.com (login in domain1.com) i can not login in test.domain1.com, the browser simply ignore set cookie header
this problem is only in chrome and firefox work just fine.
i need to say that domain1.com is https and the subdomain is http and i am not specify the domain name in set cookie response
this is my set cookie header:
login=Au5SS1V6lq9oALse450c3GHFm8zAz3zXqkBHIsgd%2FZxBn4qio%2B7iqYjPJYZMww9lxSihNB; expires=Tue, 02 Aug 2022 09:15:04 GMT; path=/; httponly
interesting part is that if i login in subdomain first i can login in domain but if i login in domain i can not login in subdomain
this is the message that chrome show me when i try to login in insecure subdomain :
this attempt to set a cookie via a set-cookie header was blocked because it was not sent over a secure connection and would have overwrite a cookie with the secure attribute
its look like chrome see my domain and subdomain one site not two different application, but why ??????????????????
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 have a page served via HTTPS. All content is public and no sensitive data is on this page. I also have resources (audio mp3) on a google cloud bucket which has no HTTPS support and is a subdomain (DNS C-NAME entry only), but is reachable via HTTPS but returns a Google certificate if accessed by https. Until now I had my server respond with a 302 redirect to my subdomain downgrading static mp3-resources from HTTPS to HTTP and it worked. See this request:
Request:
Request URL: https://x.com/q/ics/edit/r.6c19e2d99e220f648b3c1799ed05dc99.mp3
Request Method: GET
Status Code: 302
Remote Address: 172.217.19.115:443
Referrer Policy: no-referrer-when-downgrade
Response:
content-length: 259
content-type: text/html; charset=UTF-8
date: Wed, 24 Jun 2020 05:42:46 GMT
location: http://subdomain.x.com/ics/_resources/r.6c19e2d99e220f648b3c1799ed05dc99.mp3
server: Google Frontend
status: 302
x-cloud-trace-context: 3086726898e017b2b99858fcea43c5e0
But suddenly Chrome started ignoring location: http: and instead resolves the HTTPS version, which causes ERR_CERT_COMMON_NAME_INVALID and this fails the download.
I know this can be resolved by using a load-balancer, but that would almost double our hosting costs (maintenance/setup/learning costs not included!) and we really do not need a load balancer with AppEngine classic.
The problem occurred a few weeks ago the first time, but went away within a day, but is persistent now!
Does anyone know why Chrome is interpreting the redirect this way? Is this required by any specification?
Update: The only solution I found so far is to downgrade the whole page with a redirect from HTTPS to HTTP. That is really a sad solution.
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.
I have an ASP.NET MVC project under development in VS 2013 and running on localhost. A cookie is sent with the
Set-Cookie: Tx=88440; expires=Sun, 03 Apr 2016 12:49:28 GMT; domain=localhost; path=/
Chrome receives this ok. But when I refreshes the page in Chrome, the cookie Tx is not sent back to the server. Is there anything wrong with the cookie header? Does a path of / mean it will apply to all paths beneath /?
Chrome ignores localhost for cookies. Design decision apparently.
I am trying to talk to mysql from my Google Hangout app and the test code works fine from an HTML page, but gets blocked when I run it in the app .XML wrapper in a hangout.
There I get this in the console (I had to replace the URLs due to me being new here) :
<<<<<>>>>>
XMLHttpRequest cannot load XXXXXX MY file URL XXXXX. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https XXXXXX GOOGLE USER CONTENT XXXXX' is therefore not allowed access. ifr?url=app%3A%2F%2F609528936436%2Fhangout&container=hangout&view=default&lang=all&country=ALL&debu…:1
GET XXXXXX MY file URL again only with https XXXXX net::ERR_CONNECTION_REFUSED ifr?url=app%3A%2F%2F609528936436%2Fhangout&container=hangout&view=default&lang=all&country=ALL&debu…:1199
XMLHttpRequest cannot load XXXXXX MY file URL XXXXX. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https XXXXXX GOOGLE USER CONTENT XXXXX' is therefore not allowed access. ifr?url=app%3A%2F%2F609528936436%2Fhangout&container=hangout&view=default&lang=all&country=ALL&debu…:1
<<<<<>>>>>
What am I doing wrong? Thank you!
ANSWER Thanks to Gerwin Sturm:
Your problem seems to be that with the Hangout App running inside of an iframe hosted on Google servers your server refuses to send content to this different domain.
Two possible solution:
1) Set the headers on your server to allow cross-origin request. In your php script you should be able to do this by calling
header("Access-Control-Allow-Origin: *");
2) Use https://hangoutiframer.appspot.com, which allows you to run the hangout app on your own server, preventing CORS problems that way.