CODEWITHSUNDEEP
cookiesiframeasp.net-coreidentityserver4c3.js
Fred Johnson
Fred Johnson

Reputation: 2695

Cookie not being set in iframe

I have an Identity Server (v4) on one server and a web application on a different server & domain. I only need windows authentication, and everything works fine with a redirect. However, I noticed that silent sign-in works if the cookie hasn't yet expired.

If the cookie has expired, a redirect is currently necessary which works fine. Unfortunately however, this would mean if there's data the user hasnt saved on the current screen they will loose it unless I implement a caching mechanism. Instead, I want to set a hidden iframe that simply navigates to the Identity Server, auto logs in if the user is inside the company infrastructure (which they always will be).

After hours of debugging I have found that while cookies are correctly sent from the iFrame, any that are SET don't seem to work - they are in chrome debugger as a response cookie, but are not sent along on the next redirect as request cookies and I dont know why.

On response:

Cookie Options: SameSite Lax, HTTP true, Secure true, Path /

Headers:

Content-Security-Policy: default-src 'self'; object-src 'none'; frame-src localhost:44388; frame-ancestors 'self' https://localhost:44388/; sandbox allow-forms allow-same-origin allow-scripts; base-uri 'self';

Persistent-Auth: true

Pragma: no-cache

Referrer-Policy: no-referrer

WWW-Authenticate: Negotiate oRswGaADCgEAoxIEEAEAAABJ+0p/zH0aeAAAAAA=

X-Content-Security-Policy: default-src 'self'; object-src 'none'; frame-src **localhost:44388; frame-ancestors 'self' https://localhost:44388/; sandbox allow-forms allow-same-origin allow-scripts; base-uri 'self';

X-Content-Type-Options: nosniff

X-Frame-Options: ALLOW-FROM https://localhost:44388/

Upvotes: 18

Views: 36980

Answers (4)

sitesalt
sitesalt

Reputation: 55

I found that this worked for me - setting SameSite as "None" - and some more info on what that means here.

It's all from the PHP manual, but the other answers here helped me find the solution.

Apparently, browsers no longer allow you to set whatever you want in an iframe, I was trying to handle a session in an iframe, loaded on a different domain and while doing that, I noticed that a different session was being created for the OTHER domain instead of what I was loading in the iframe. This seems to have fixed it. I am still testing but it's the first thing that worked since I started looking for a fix this morning.

Upvotes: 2

Alberto Perez
Alberto Perez

Reputation: 1077

From August 2020 you have to set SameSite to None, and secure to True.

In php could be done with something like:

setcookie("variable", 1, time() + (86400), "/; SameSite=None; Secure");

In javascript will be similar after path option. document.cookie="cookiename="+0+";Domain=.yourdomain.net; path=/; SameSite=None; Secure"

Upvotes: 21

Eric
Eric

Reputation: 2390

I was seeing this same behavior when my parent website is localhost and the frame is not localhost. Strangely, the cookie works fine when both the parent and frame are not localhost, even though they are also not the same domain. I used the SameSite "None" setting for the cookie that multiple comments recommended to get around this problem. It seems like it should work with either Strict or Lax, since the ajax queries I am making are from within the frame, which is technically the same site, but for some reason, having a different domain for the frame's parent is throwing it off (though only when the parent is localhost).

Upvotes: 2

Red Puffle
Red Puffle

Reputation: 94

To fix a similar issue -- authenticated site inside an iframe from a different hostname -- I had remove the SameSite attribute that I had set up.

Really there are three options for SameSite, from most strict to least: Strict, Lax, and "don't set it at all".

Upvotes: 0

Related Questions