Orchardcore: Test Chrome samesite changes

[sebastienros]

[hishamco]

@MatthijsKrempel could please have a look?

[MatthijsKrempel]

Sure!

[MatthijsKrempel]

Tested it with incognito mode, seems to login just fine.
That is what I could fine about what Chrome considers "safe mode".
If that is not the issue, I need more details.

[sebastienros]

Did you switch the chrome feature on before?

[MatthijsKrempel]

@sebastienros got a link I can follow, because I feel like I am chasing a rabbit.

[sebastienros]

Sorry, I should have said "SameSite":

https://www.chromium.org/updates/same-site/test-debug

[deanmarcussen]

@MatthijsKrempel am receiving this console warning on a non http site during login which fails (latest chrome / mac will get the version tomorrow)

A cookie associated with a resource at ... was set withSameSite=Nonebut withoutSecure. It has been blocked, as Chrome now only delivers cookies markedSameSite=Noneif they are also markedSecure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032.

[MatthijsKrempel]

The login cookie is secure, so need a bit more info on your situation.

[deanmarcussen]

try with non http. then it is not secure :)

[MatthijsKrempel]

I reproduced it when creating a non https site :)

Thanks @deanmarcussen , will have a look.

[MatthijsKrempel]

@deanmarcussen I think the only option is to move to HTTPS if you want to be able to log in to your site. It seems google is actively pushing towards this goal.

The options we have is to set the samesite mode to strict, but if your site was ever hosted on https the new cookie will not be overwritten by chrome. Since it values secure cookies over non secure ones.
Then the difficulty would be that we need to set it to samesite none when activating the OpenId module, to support the prompt=none.

Since we have secure cookies during development time, it is ultimately a decision if we want to support http production scenarios for Orchard Core sites.

[deanmarcussen]

It is indeed a conundrum...

Chrome is of course not the only browser in the world ;)

I think we should explore the possibilities here because whatever we do, it needs to be reasonably transparent for users, or gitter will be busy...

• Development. Yes, I've pretty much given up trying to develop on Chrome without https. BUT a default dotnet run or similar will open both port 5000 and 5001. So it would be a hard story to tell everyone that you can run your development site on 5000 but you won't be able to login with chrome... Gitter will be busy

• Production. http production scenarios can be valid when using proxy servers, or edge fronts (which hold the ssl cert). Often I load a certificate on the backing server regardless, for admin access (because... Chrome), but in that scenario you wouldn't use http -> https redirection.

Would it be possible to call services.ConfigureApplicationCookie(c => ... SameSiteMode.None in the OpenId module Startup, which would override the default configuration when OpenId is active?

Does it even make sense to do so?

[MatthijsKrempel]

For productionservers behind a proxy we have the ReverseProxy module that will make the site act as if it is running op HTTPS, so that is not an issue.

For your second comment, I will have to have a look, I think it should be feasable,.

I would say it would be the most sensable thing to do and we can sell that an OpenId server has to run on HTTPS.

[JoshuaHallValid]

It appears chromium is slowly rolling out the new SameSite behavior to Chrome 80 Stable users through gradually increasing rollouts. SameSite=None; Secure needs to be added. To replicate the issues caused by the newly enforced requirements follow these steps:
Open a new tab in Chrome > Type chrome://flags/ in the address field >Search "samesite" in flags > Enable "SameSite by default cookies" and Enable "Cookies without SameSite must be secure".

Article explaining the issue and coded example to remedy the issue:
https://www.thinktecture.com/en/identity/samesite/prepare-your-identityserver/

I hope this will help to get this issue taken care of fairly quickly.

[MatthijsKrempel]

We already support this on Https sites.

---

From: Joshua Hall [e-mail]
Sent: Thursday, March 19, 2020 5:29:26 PM
To: OrchardCMS/OrchardCore [e-mail]
Cc: Matthijs Krempel [e-mail]; Mention [e-mail]
Subject: Re: [OrchardCMS/OrchardCore] Test Chrome samesite changes (#5712)

It appears chromium is slowly rolling out the new SameSite behavior Chrome 80 Stable users through gradually increasing rollouts. SameSite=None; Secure needs to be added. To replicate the issues caused by the newly enforced requirements follow these steps:
Open a new tab in Chrome > Type chrome://flags/ in the address field >Search "samesite" in flags > Enable "SameSite by default cookies" and Enable "Cookies without SameSite must be secure".

Article explaining the issue and coded example to remedy the issue:
https://www.thinktecture.com/en/identity/samesite/prepare-your-identityserver/

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/OrchardCMS/OrchardCore/issues/5712#issuecomment-601278543, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMGIKTLMFYO67AHDWCBPALRIJB6NANCNFSM4LGUYS6A.

[sebastienros]

Can we consider this closed?

[deanmarcussen]

I believe so, login is now working with http, and chrome is not reporting any same site errors.