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...")
 
(Full Title or Meme)
Line 1: Line 1:
 
==Full Title or Meme==
 
==Full Title or Meme==
 +
An HTTP response of 302 or 303 is consider 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==
 +
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 200: Line 202:
 
Eloff
 
Eloff
 
  May 21 '20 at 22:14
 
  May 21 '20 at 22:14
Add a comment
 
  
 
==References==
 
==References==
  
 
[[Category: Glossary]]
 
[[Category: Glossary]]

Revision as of 21:12, 10 November 2021

Full Title or Meme

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

Context

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. 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. – 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.

Solution:

Use 127.0.0.1 instead of localhost.

Share Follow 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! – GlenPeterson

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)

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

Share 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 – 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).

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. – 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 – 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:

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
               }

Share Follow answered Oct 2 '17 at 12:25

Michael Freidgeim 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

References