I need to fix a problem which appeared after Chrome v80 which introduced a default option for Cookies of: Block 3rd Party cookies in Incognito mode.
Use case:
site A (https://siteA.com)
site B (https://siteB.com)
Site A includes an iframe of Site B, which require logging in
Problem:
No session cookie is stored so session could not be started.
FYI, This work fine in default mode of Chrome.
A cookie setting of: SameSite=None is set on Site B.
It’s been a while since I did something like this but basically the solution is to read the cookie on site A, wait for site B to load in the iframe, and then use the PostMessage API to pass the cookie value to site B and set the Cooke there.
You may run into some issue with JS being blocked from reading a cookie and then passing it, but this can be got around by using async functions.
Alternatively proxy Site B, on Site A.
Related
I have a web application and we are calling a third party to process some data. Once it's done, the third party will redirect back to my application (It's a post redirection). To keep the session, we are using cookies. After the google chrome update, where the default values for samesite=Lax, I've updated our cookies to pass as samesite=None; Secure to overcome this issue. Now after google chrome version 91, this implementation is not working and I'm getting a session expiry issue. Can somebody help to fix this issue for google chrome version 91 and after? I'm using java
The best that we have been able to come up with is a client side meta refresh. When the third party posts back to our application, we have a page filter that will send it to a "refreshMeta" page similar to https://www.w3.org/TR/WCAG20-TECHS/H76.html. This has to happen without calling .getSession() anywhere because that will cause a new session to be created. This causes the page to refresh in the browser and send all original cookies back to the server because its coming from the same domain and a new session wasnt created.
I will say this worked for a while but it looks like there was change in Tomcat that's preventing this approach from working like it did on earlier versions, which is why I'm back looking for another solution.
I ran into such a problem.
When I run the application on my laptop (Linux/Ubuntu 18) in the developer console in the Chrome browser, I have this message
A cookie associated with a cross-site resource at
http://pubsub.rtschannel.com/ was set without the SameSite
attribute. A future release of Chrome will only deliver cookies with
cross-site requests if they are set with SameSite=None and Secure.
You can review cookies in developer tools under
Application>Storage>Cookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.
On another laptop (Linux/Ubuntu 16) in the Chrome browser, when the application is launched locally, there is no such message.
I tried to find at least some information on this subject, but alas I couldn’t. The only thing I could find was the link inside the message that it was a browser bug and in Chrome version number 80 it should be fixed and this setting would be added by default.
Please tell me, does it depend on the browser settings, or can I somehow influence this message programmatically? Can I clean it somehow?
On the project, I use angularjs if this can help.
Thanks.
These warnings are purely informational at the moment and do not affect site functionality. This behaviour will not be enforced until Chrome 80 which is due to hit stable in Feb 2020.
You can simply turn off the messages by setting chrome://flags/#cookie-deprecation-messages to Disabled. However, that is purely affecting the display of the messages.
If the pubsub.rtschannel.com is not your domain, e.g. it's a third-party service you use, then it's that domain that will be responsible for updating the cookies.
If it is your domain, then you need to review the cookie usage and set an appropriate value for the SameSite attribute on the cookie. You can find more context and guidance on https://web.dev/samesite-cookies-explained.
I have created several virtual hosts for my development processes. They were working just fine till yesterday. But in my chrome app, today they stopped working. Chrome shows: NET::ERR_CERT_AUTHORITY_INVALID
All my vhosts end with .dev. I changed one .dev to .work and its again working. But I can not do this for all vhosts as there are too many of them. What do I do?
PS:
They are working fine in firefox.
The error remains same in chrome incognito mode.
I tried clearing cache and hard reload, deleted my history and cache, restarting chrome even windows multiple time, nothing works.
In one solution, I found an exception can be included in chrome://net-internals/#hsts. I tried deleting domain in there but somehow it still appears in Query Domain search.
Chrome have switched the .dev sub domain to HTTPS only.
They have done this by turning on HSTS for this top level domain, but by preloading this in the Chrome code rather than sending the HSTS header. This means it cannot be switched off in the chrome://net-internals/#hsts screen.
More info:
https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
So you’re only options are:
Update you’re vhosts to a different TLD (e.g. .test). And yes this might be painful because you have so many.
Move to HTTPS by creating a certificate and updating your URLs. A self signed certificate that you can create yourself will do, however note that HSTS not only blocks accessing the site over plaintext HTTP, but also prevents you clicking through certificate errors. So you’ll need to manually accept any certificate to your trust store before it can be used.
The chrome team have been pushing HTTPS more and more and certain features are now HTTPS-only so even dev envs will need it now. So maybe it’s finally time take the effort to make the switch.
I am working on "Keep Me Log in" part of a site.However, when I close the chrome, only local cookies that I am working on are deleted. Other cookies from other sites remains. Does it have to be like that or is there any option for not-deleting the local cookies?. Thanks.
You need to be more specific.
There's cookies and localStorage, it's 2 different client persistance option. Neither get delete by navigator (Unless you're in private browse).
Cookies have a lifetime, maybe you don't set it right. Are you using a framework that can interferr here ?
Moreover, Chrome doesn't support cookies on localhost.
SharePoint 2013 doesn't use Session cookies by default, but rather persistent cookies. Based on several articles, including this one, you can force SharePoint to use session cookies by the following PowerShell command. I ran this command in my SharePoint environment.
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
My goal is to make a user re-authenticate when they close and re-open their browser. For both Forms Authenticated users and Windows Authenticated users, this works great in Firefox and IE. However, in Google Chrome, when I close/re-open the browser and navigate to my SharePoint site, it remembers the user that I was authenticated as before I closed my browser; which is baffling, considering this is supposed to be a Session cookie. This happens for both Forms Authenticated users, and Windows authenticated users.
FedAuth Session cookie, given by SharePoint, as seen in Chrome
Any ideas why Google Chrome (but not IE or FF) is "remembering" my credentials upon browser close/open?
SharePoint Version: 2013, on-premise.
Chrome Version: 42.0.2311.152
Other Notes:
WindowsTokenLifetime is set to it's default value, 10hrs
FormsTokenLifetime is set to 2 minutes
LogonTokenCacheExpirationWindow is set to 1 minute
Update:
I tried closing all identifiable Chrome.exe processes via Taskmgr, but the next time I opened my browser, it still remembered me. However, I restarted my computer, opened the browser, and it didn't remember me that time. I don't think this is a SharePoint issue, but rather a Chrome issue. My guess is that some Chrome process is staying alive somewhere, even though it appears to be closed, thus allowing the "Session" to remain open. Still investigating...
Apparently, when you let Chrome run in the background, the Session cookies aren't expired (even though you've closed the browser). Disabling background mode causes Chrome to forget your Session cookie, as it should.
Note: I'm curious if this a bug in Chrome. This behavior seems to go against what a Session cookie is.
a cookie that is erased when the user closes the Web browser. The session cookie is stored in temporary memory and is not retained after the browser is closed
Update:
According to Google, this is expected behavior (though I'd consider that notion debatable). Also, another SO user also came across the same issue.