Redirect

Full Title or Meme

An HTTP response of 301 or 302 is designed to Redirect the user to a different web site.

Context

The context for this page, as for all in this wiki is to discuss the use of the feature in Identity Management.

Both forms of redirect send site users from one URL, or webpage, to another. There is a simple difference between a 301 and 302 redirect: a 301 redirect indicates that a page has permanently moved to a new location, meanwhile, a 302 redirect says that the page has moved to a new location, but that it is only temporary.

Since all interesting web sites now (2020) support HTTPS for all requests, only the HTPS cases are of concern for Identity Management.

Cookies

According to this blog post:all major browsers, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Opera (12.11) both on Windows and Mac, set cookies on redirects. This is true for both 301 and 302 redirects.

As @Benni noted :

https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies

The SameSite attribute of a cookie specifies whether the cookie should be restricted to a first-party or same-site context. Several values of SameSite are allowed:

• A cookie with "SameSite=Strict" will only be sent with a same-site request.
• A cookie with "SameSite=Lax" will be sent with a same-site request, or a cross-site top-level navigation with a "safe" HTTP method.
• A cookie with "SameSite=None" will be sent with both same-site and cross-site requests.

It depends on the samesite policy: With strict it still doesn't work. –

IE and Edge are ignoring Set-Cookie in redirect response when domain of the cookie is Localhost.

Solution:

Use 127.0.0.1 instead of Localhost.

Share Follow answered Oct 28 '16 at 11:19

IE and Edge may have "fixed" this so they won't set cookies for 127.0.0.1 either. Doh! And they wonder why developers don't all love IE... Your answer still ended about 4 hours of head-scratching for me. Thanks! – GlenPeterson

Mar 15 '17 at 22:32

Most browser are accepting cookies on 302 redirects. I was quite sure of that, but I made a little search. Not all modern browsers. Internet archive Link from a now removed/dead/ microsoft connect Q/A on Silverlight Client HTTP Stack ignores Set-Cookie on 302 Redirect Responses (2010)

I think we now have a replacement for IE6 and it's Windows Mobile browsers...

The forum page you specified cannot be accessible with the URL. Do you mean IE6 and Windows Mobile browsers aren't? –

link has moved. I,ve set a new link with quite the same content. and I meant IE specific versions for mobile add their own set of bugs –

Here is the Chromium bug for this issue (Set-cookie ignored for HTTP response with status 302).

I think they fixed it. The bug report still says "WontFix", but on my Chrome browser it works. –

@Michael note that Chromium is not Chrome: lifewire.com/chromium-and-chrome-differences-4172101 - that means that while it might work in Chrome that isn't necessarily true for Chromium –

I just ran into this problem with both Firefox and Safari, but not Chrome. From my testing, this only happens when the domain changes during the redirect. This is typical in an OAuth2 flow:

OAuth2 id provider (GitHub, Twitter, Google) redirects browser back to your app
Your app's callback URL verifies the authorization and sets login cookies, then redirects again to the destination URL
Your destination URL loads without any cookies set.
For reasons I haven't figured out yet, some cookies from request 2 are ignored while others are not. However, if request 2 returns a HTTP 200 with a 
Refresh header (the "meta refresh" redirect), cookies are set properly by request 3.

Share Follow answered Aug 7 '20 at 12:49

Kiran Jonnalagadda 2,32611 gold badge2626 silver badges2626 bronze badges 6 I suspect that the reason for this wrt oauth callback issues is samesite=strict. For the callback request the browser still thinks that the originator is google (or whichever oauth provider you use). Hence if you set a samesite=strict cookie in your 302 response then the browser probably thinks "ah ha! this is a cross-site request coming from Google to your site" and hence doesn't send the cookie when requesting the redirected url. The fix is to use a meta-refresh as you've done, so your request comes from your own site. I could be talking crap, but that's my current thinking. – Ilan

Sep 20 '20 at 15:33

@Ilan wow thank you. I kind of suspected it had to do with this, but your comment confirmed it. – DOMZE

Jul 27 at 19:25

Add a comment

8

This is a really frowned upon approach, but if you really want to not rely on 30x set-cookie browser behavior you could use an HTML meta http-equiv="refresh" "redirect" when setting the cookie. For example, in PHP:

<?php

   ...
   setcookie("cookie", "value", ...);
   url="page.php";

?> <html> <head><meta http-equiv="refresh" content=1;url="<?=$url?>"></head> <body><a href="<?=$url?>">Continue...</a></body> </html> Server will send Set-Cookie with a 200 instead of a proper 300x redirect, so browser will store the cookie, and then perform the "redirect". The <a> link is a fallback in case browser does not perform the meta refresh.

Share Follow edited Apr 17 '20 at 12:15 answered Jul 30 '19 at 15:26

MestreLion 10.7k22 gold badges5555 silver badges5252 bronze badges Add a comment

4

Encountered this issue while using OpenIdConnect / IdentityServer on .Net, where a separate API (different hostname) handles authentication and redirects back to the main site.

First (for development on Localhost) you need to set CookieSecure option to SameAsRequest or Never to deal with http://localhost/ not being secure. See Michael Freidgeim's answer.

Second, you need to set the CookieSameSite attribute to Lax, otherwise the cookies do not get saved at all. Strict does not work here!

Share Follow edited Sep 17 '20 at 7:56 answered Sep 1 '20 at 15:23

Willem 4,5382222 silver badges4040 bronze badges 1 To clarify a bit - the cookies do get saved. They just don't get sent to the next request, so it looks like they aren't getting saved. – jjnguy

Mar 6 at 14:45

Add a comment

0

In my case I set CookieOptions.Secure=true, but tested it on http://localhost., and browser hide cookies according to the setting.

To avoid such problem, you can make cookie Secure option to match protocol Request.IsHttps,e.g.

new CookieOptions()

             {
                Path = "/",
                HttpOnly = true,
                Secure = Request.IsHttps,
                Expires = expires
            }

In that case don't set the secure flag. The whole point of the flag is to tell the browser to only use the cookie when connecting over HTTPS. Conditionally setting the flag changes the semantics somewhat, and you lose the cookie transitioning from HTTPS -> HTTP, but not when going from HTTP -> HTTPS. All this is orthogonal to what browsers do with Set-Cookie headers on 302 redirects however. –

Safari

We are loading ASWebAuthenticationSession with a request URL which internally checks for the active session and cookies then returns the AuthCode in the Redirection URI, but sometime this is failing due to the cookie lost in between the requests. We see the cookies are present for first few requests and getting missed in between the request while redirecting to different URLs.

Is anyone faced the similar issue with ASWebAuthenticationSession?

This issue is observed in iOS 13 and above devices only, not in the simulator. Also, we if give 30 secs delay between Login session and AuthCode session it always works.

WebKit SafariServices AuthenticationServices Safari and Web

I found the root cause for missing cookies, If i turn off "Prevent Cross-Site Tracking" in safari settings it works fine.

• Intelligent Tracking Prevention (ITP) in Safari 14 now in the wiki page Intelligent Tracking Prevention.