WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
24332
OpenID authentication redirect stops in Safari, Chrome
https://bugs.webkit.org/show_bug.cgi?id=24332
Summary
OpenID authentication redirect stops in Safari, Chrome
Shawn Pearce
Reported
2009-03-03 11:30:16 PST
When using a Google Account to login to Gerrit Code Review (review.source.android.com) the OpenID authentication process stops when a 302 redirect is issued by www.google.com and is not executed by WebKit. Observed in both: Safari 3.2.1 (5525.27.1) Chrome 1.0.154.48 Steps to reproduce: - Have a Google Account ready (
https://www.google.com/accounts/NewAccount
) - Go to
http://www.google.com/
- Verify you are signed into the Google Account (check top right). If not, sign in now with "Sign In" link. - Go to
https://review.source.android.com/
- Click "Sign In" in top right - Click "Sign in with a Google Account" - DO NOT CHECK "Remember me" - Click "Continue Sign-In" button - IFrame gets stuck. It ignored a 302 redirect sent by www.google.com. This exact procedure works fine in Opera, Firefox, MSIE, and older versions of Safari (3.0). However, a slightly different procedure permits the login to work: - Go to
http://www.google.com/
- Verify you are signed out. Click "Sign Out" in top right if necessary. - Go to
https://review.source.android.com/
- Click "Sign In" - Click "Sign In" in top right - Click "Sign in with a Google Account" - Enter your Google Account information - Sign In - DO NOT CHECK "Remember me" - Click "Continue Sign-In" button
Attachments
Add attachment
proposed patch, testcase, etc.
Shawn Pearce
Comment 1
2009-03-03 17:05:41 PST
Turns out to be a combination of factors, all of them unrelated to WebKit. The server in question is Jetty, with a 4096 byte limit on the entire HTTP request. The OpenID authentication process uses a relatively large cookie (about 1.5 KB) and long URLs with lots of data encoded in them. Combined with the standard headers used by the Safari and Chrome user agents, this overflows Jetty's request limit. (Other browsers must be using slightly smaller user agent and accept headers, and thus avoid the overflow.) - Increasing the Jetty request buffer is one possible solution. - Switching the OpenID peers to using POST based requests is another. Neither of which has anything to do with WebKit, or a browser implementing it.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug