Difference between revisions of "Redirect"

From MgmtWiki
Jump to: navigation, search
(Created page with "==Full Title or Meme== According to this blog post: http://blog.dubbelboer.com/2012/11/25/302-cookie.html all major browsers, IE (6, 7, 8, 9, 10), FF (17), Safari (6.0.2), Op...")
 
(Safari)
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
 +
An HTTP response of 301 or 302 is designed to [[Redirect]] the user to a different web site.
  
According to this blog post: http://blog.dubbelboer.com/2012/11/25/302-cookie.html 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.
+
==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 [http://blog.dubbelboer.com/2012/11/25/302-cookie.html 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 :
 
As @Benni noted :
Line 8: Line 17:
  
 
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:
 
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.
  
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.
 
Share
 
Follow
 
edited Nov 25 '20 at 8:06
 
answered Nov 13 '13 at 7:47
 
  
gavenkoa
 
39.1k1414 gold badges217217 silver badges264264 bronze badges
 
Unfortunately this list does not include Chrome, so we cannot exactly say all major browsers... –
 
MestreLion
 
Jul 30 '19 at 15:02
 
3
 
@MestreLion: on my Chrome browser it works. So.. I think we can say that t it finally works now, in 2019. –
 
Michael
 
Aug 11 '19 at 15:14
 
1
 
 
It depends on the samesite policy: With strict it still doesn't work. –  
 
It depends on the samesite policy: With strict it still doesn't work. –  
Benni
 
Nov 25 '20 at 0:58
 
Add a comment
 
 
47
 
 
One notice (to save developer's life):
 
  
 
IE and Edge are ignoring Set-Cookie in redirect response when domain of the cookie is localhost.
 
IE and Edge are ignoring Set-Cookie in redirect response when domain of the cookie is localhost.
Line 46: Line 34:
 
answered Oct 28 '16 at 11:19
 
answered Oct 28 '16 at 11:19
  
Michal Maťovčík
 
73866 silver badges1111 bronze badges
 
13
 
 
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! –  
 
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
 
GlenPeterson
 
  Mar 15 '17 at 22:32
 
  Mar 15 '17 at 22:32
Encountered this on Chrome Version 92.0.4515.159 (Official Build) (x86_64). –
 
Anton Yurchenko
 
Aug 21 at 11:07
 
Add a comment
 
 
42
 
  
 
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)
 
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)
Line 63: Line 42:
 
I think we now have a replacement for IE6 and it's Windows Mobile browsers...
 
I think we now have a replacement for IE6 and it's Windows Mobile browsers...
  
Share
+
The forum page you specified cannot be accessible with the URL. Do you mean IE6 and Windows Mobile browsers aren't? –
Follow
 
edited Feb 19 '18 at 9:10
 
answered Jan 14 '11 at 21:14
 
  
regilero
 
28.3k66 gold badges5757 silver badges9797 bronze badges
 
1
 
The forum page you specified cannot be accessible with the URL. Do you mean IE6 and Windows Mobile browsers aren't? –
 
hiroshi
 
Feb 12 '13 at 2:15
 
1
 
 
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 –  
 
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 –  
regilero
 
Feb 13 '13 at 13:08
 
Add a comment
 
 
20
 
  
 
Here is the Chromium bug for this issue (Set-cookie ignored for HTTP response with status 302).
 
Here is the Chromium bug for this issue (Set-cookie ignored for HTTP response with status 302).
  
Share
 
Follow
 
answered Jun 16 '16 at 17:05
 
 
lammy
 
3,60522 gold badges2020 silver badges2222 bronze badges
 
1
 
If this is true it is really bad news indeed :-( –
 
MestreLion
 
Jul 30 '19 at 15:04
 
 
I think they fixed it. The bug report still says "WontFix", but on my Chrome browser it works. –  
 
I think they fixed it. The bug report still says "WontFix", but on my Chrome browser it works. –  
Michael
+
   
  Aug 11 '19 at 15:17
 
1
 
 
@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 –  
 
@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 –  
Thomas
 
Aug 30 '19 at 9:09
 
Add a comment
 
 
9
 
  
 
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:
 
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
+
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 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.
+
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.
+
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
 
Share
Line 179: Line 127:
  
 
new CookieOptions()
 
new CookieOptions()
                {
+
              {
                    Path = "/",
+
                Path = "/",
                    HttpOnly = true,
+
                HttpOnly = true,
                    Secure = Request.IsHttps,
+
                Secure = Request.IsHttps,
                    Expires = expires
+
                Expires = expires
                }
+
            }
Share
+
 
Follow
+
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. –
answered Oct 2 '17 at 12:25
+
 
 +
===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.
  
Michael Freidgeim
+
* [https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/ Intelligent Tracking Prevention (ITP) in Safari 14]
22.8k1515 gold badges131131 silver badges158158 bronze badges
 
2
 
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. –
 
Martijn Pieters
 
 
Jan 26 '19 at 14:22
 
2
 
That time when the answer with -3 votes solves the problem. I was setting Secure=true, but forgot that on localhost I'm just using http to test it with. Noob mistake. Use secure=request.is_secure in flask. –
 
Eloff
 
May 21 '20 at 22:14
 
Add a comment
 
  
 
==References==
 
==References==
  
 
[[Category: Glossary]]
 
[[Category: Glossary]]

Latest revision as of 22:05, 10 November 2021

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.

References