I have two tomcat instances that I've been authenticated to from my browser and one is called from a different domain. Usually after configuring properly cors on this tomcat instance, the request will forward the JSESSION ID and be successful. But Chrome browser (v86.0.4240.80) is not forwarding anymore the JESSION ID and the request is unauthorized.
What could be the issue?
Here is the reason: https://www.chromestatus.com/feature/5088147346030592
You need to set SameSite=None to notify Chrome that JSESSIONID can be forward from another domain. (https://tomcat.apache.org/tomcat-8.5-doc/api/org/apache/tomcat/util/http/SameSiteCookies.html)
Related
I search everywhere I found 0 information about this specific redirect.
I have app that I need to use "HTTP" to function, recently chrome started to redirect my app to HTTPS automatically, and If I put HTTPS to HTTP code in my app it cause infinite loop.
My app is not on the HSTS preload domain list, my app and server have no redirect code to HTTPS.
Request URL: http://4444.com/z.txt
Request Method: GET
Status Code: 307 Internal Redirect (from disk cache)
Referrer Policy: strict-origin-when-cross-origin
Cross-Origin-Resource-Policy: Cross-Origin
Location: https://4444.com/z.txt
Non-Authoritative-Reason: DNS
This does not happen on any other browser other than chrome.
Does that mean chrome is targeting my host's dns to make sure all website hosted on the DNS is HTTPS?
If yes I think this is very bad move from google as I can't find any announcement by google that they will start forcing https on websites. This could break many non https sites without prior warning.
If not what can I do to fix this issue?
Thanks
I encountered the same problem just like you, and that situation didn't happen all the time, sometimes when I open another window as incognito mode, the redirect disappeared!Sooooo Annoying:(
And I just tried another way, it seemed to work fine with me!
go to : chrome://net-internals/#dns, and click Clear host cache , then refresh your page, the redirect will be gone!
Even if the "Always use secure connections" (chrome://settings/security) is disabled, chrome will still try to use HTTPS if it finds HTTPS records in DNS, as per #dns-https-svcb flag - "Support for HTTPS records in DNS" (chrome://flags/#dns-https-svcb) - which is enabled by default.
This causes the loop leading to the ERR_TOO_MANY_REDIRECTS with Non-Authoritative-Reason: DNS.
Either remove any HTTPS record from the host zone file or disable the aforementioned flag from chrome.
Did you access websites using VPN? VPN server seems able to force http to https
I'm trying to set up Cookie Authentication in Blazor WebAssembly, running in Chrome.
WebApp runs on https://localhost:44342
WebApi runs on https://localhost:44377
After a post request (with PostAsJsonAsync) to https://localhost:44377/user/loginuser with valid credentials, the WebApi sends back a response header with Set-Cookie: .AspNetCore.Cookies=...
That cookie seems to be rejected by the browser, because
I don't see it in F12 -> Application -> Cookies
Subsequent requests don't have the cookie attached
I researched the problem on the net extensively. I found loads of hints and explanations. Including configuring CORS, using the IP instead of localhost, setting cookie properties like SameSite, HttpOnly, Expiration and Domain or using chrome internals for further investigation.
None of that helped. Set-Cookie is still ignored by the browser.
Does anyone have a good idea on how I could proceed? Thanks
I had probably the same problem.
Chrome browser is denying the cookie ‘couse the domain is not using SSL and the cookie policy uses samesite:none.
I solved using a certificate in IIS (using HTTPS instead of HTTP). I had this problem only in production. For the development environment, when you create the project, visual studio asks if you want register a development certificate. Check yes.
I'm a front-end developer working on an application where the login/ response put a Session-Cookie on the client. The later request will be authorized since the user "logged in".
Starting from Chrome 80
All cookies without a SameSite attribute will be treated as if they had SameSite=Lax specified. In other words, they will be restricted to first-party only (server and client on the same domain).
If you need third-party cookies (server and client on different domains), then they must be marked with SameSite=None.
Restricted to first-party by default
Set-Cookie: cname=cvalue; SameSite=Lax
Allowed in third-party contexts
Set-Cookie: cname=cvalue; SameSite=None; Secure
For my application, I want the default behavior. My client and server running on the same domain in production. But in development I'm working from localhost (different domain).
Up until now, chrome had special flag under chrome://flags - SameSite by default cookies. I could Enable this flag on my development machine and the login passed. And in production, I didn't need this flag because I wanted the default behavior.
Starting from Chrome 91
The SameSite by default cookies flag was removed. This means that from this version I can't login into my app, without deploying it to production.
Does anybody knows how can I get the Session-Cookie while working from localhost. But still keeping the security of SameSite=Lax. If possible with client only changes, but if needed also with server changes.
Chrome DevTools - SameSite error message
Chrome 80 Flags menu - These flags removed in Chrome 91
Update
I tried to solve this by making the server use SameSite=None (development only).
This causes a different error: Connection isn't secure. This is because when using SameSite=None you are required to add the suffix Secure and of curse use HTTPS connection.
Secure connection has its own problems like having to pay for a Certificate in development.
Workaround: Downgrade Chrome
This is not a solution! just a temporary workaround for anybody like me how got his work halted due to this update.
Uninstall Chrome
Go to "Add or remove programs" and uninstall Chrome. Notice that user data like cookies and saved browser passwords may be lost.
Download Chrome v90 from slimjet.com, or from any other site. Then install Chrome.
Prevent auto-update Chrome, according to this StackOverflow solution: open C:\Program Files (x86)\Google\Update
rename the file GoogleUpdate.exe to GoogleUpdate2.exe.
This will cause Chrome to not find the update package.
Update Flags - Open Chrome and type: chrome://flags
Search #same-site-by-default-cookies and Disable the flag
I have found a way to fix it and share it with everyone :-)
Description appears in the issues section:
Specify SameSite=None and Secure if the cookie should be sent in
cross-site requests. This enables third-party use.
In the Developer Tools section, go to the Application tab, and on the left side to Cookies:
The cookie that you want to share with other domains, mark the Secure
check and in Samesite put None. Update the site tab locally and you
will be able to use the cookies that allow you to send through the
domain of origin
I hope this brightens your day
As of Chrome v107 (Nov 2022)
I had a similar issue, spent a few hours digging, and what I found is that the only solution for Chrome is to make your front-end connection secure, ie https (using a proxy for instance): Link
An alternative solution is to use Firefox and set: about:config > network.cookie.sameSite.noneRequiresSecure=false. This allows SameSite=None; Secure=false
In our case, we are able to also run our server locally on a different port and point our client app to that localhost address for development purposes.
For example, I have the client app running on localhost:1234 and sending requests to a local copy of the server running on localhost:5678. This ensures that cookies are set successfully since the client and server are now "SameSite".
Admittedly, this is perhaps more of a workaround than a solution, but I hope it helps in the short term.
If you want to perform "unsafe" CORS requests (which means performing a POST/PUT/DELETE request) you will need to modify the tomcat conf/context.xml file, to set sameSiteCookies to "none" instead of "lax".
...
<!-- default samesite cookies configuration, for CORS set sameSiteCookies to "none" and configure bundle for HTTPS -->
<CookieProcessor sameSiteCookies="none" />
...
You can set the SameSite attribute manually to "None" + tick "Secure" inside the devtools for development.
That way you would not have to modify your production environment (keep the cookies as SameSite=Lax).
I'm running my aspnet core application locally on http://localhost:5002 and for some reasons I don't want to use https. It uses OpenIdConnect middleware for authentication and it produces temporary cookie as shown below:
As a result Chrome blocks these cookies because of missing secure flag. From the other hand this request is HTTP (insecure) and it's impossible to mark the cookies secure. The only way I see is to avoid using HTTP and switch to HTTPS which is not a good option for me for local development. Can I still use HTTP + OpenIdConnect middleware + Crome and what is a workaround?
Perhaps this could shed some light- LINK.
From the article
Chrome is changing the default behavior for how cookies will be sent in first and third party contexts.
Cookies that do not specify a SameSite attribute will be treated as if they specified SameSite=Lax, i.e. they will be restricted to first-party or same-site contexts by default.
Cookies that are intended for third-party or cross-site contexts must specify SameSite=None and Secure.
Note: this also means cross-site or third-party cookies are restricted to secure / HTTPS connections only.
Since, I am guessing, your auth server is server from another domain its a third-party cookie, so it falls under the new Chrome (>= v80) policies.
The workaround here would be either a downgrade in your Chrome version or use a browser without these restrictions.
We have a web portal and I need to add HSTS header in the response.
Ours is an on-premise solution, so we use a self-signed certificate. I have added the hsts header in the response & I need to check whether it really works.
I understand that for HSTS to work, there shouldn't be any certificate issues & first we need to access https://somesite.com then in the next pass http request will be automatically redirected to https at client side itself.
So, I installed our self-signed certificate in the chrome browser & restarted the browser. Now my connection to our web application was secure. But HSTS doesn't seem to work. In the successive calls to http://somesite.com, still we redirect (302) to https (automatic client side redirection to https doesn't happen). One thing to note here is, there is no domain name associated with our web application, we access it with our server's ip within our comapany's LAN.
Any idea how to get HSTS working?