[Webkit-unassigned] [Bug 139683] "Allow from current website only" privacy setting strips cookies from 302 redirects

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 1 13:11:55 PDT 2015


https://bugs.webkit.org/show_bug.cgi?id=139683

--- Comment #1 from Patrick Toomey <ptoomey3 at biasedcoin.com> ---
In order to work around this issue for our users we changed all our OAuth redirects to use a meta refresh instead of performing a 302 redirect. This generally works, but there are scenarios where it is not ideal. For example, we found one scenario where a page embedded something like the following

`<img src="https://some_oauth_app/generate_some_image?width=50&length=50">`

The above is a reference to an OAuth app that will perform the OAuth dance with GitHub.com if the user doesn't currently have an active session. Unfortunately, it looks like subresource requests like this will not follow meta refresh based redirects. So, the only way to not break these uses is to use a 302 redirect. But, that brings us back to the original issue described above.

This seems to be an issue a number of people have encountered:

https://github.com/intridea/omniauth-oauth2/issues/72
https://github.com/zotonic/zotonic/issues/902

People seem to generally be working around it using this meta refresh approach. This Safari behavior seems to break OAuth in a fundamental way. OAuth applications are required to prevent CSRF during the OAuth dance by passing a `state` value. This value is generally tracked in the originating site's session. However, by stripping cookies on the final redirect the originating site has no session with which to validate `state`.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150901/551ea2c2/attachment.html>


More information about the webkit-unassigned mailing list