WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WORKSFORME
28244
Logout doesn't work for some sites
https://bugs.webkit.org/show_bug.cgi?id=28244
Summary
Logout doesn't work for some sites
Tim McConnell
Reported
2009-08-12 18:46:10 PDT
On SharePoint and as demonstrated by many posts on the web, Safari has problem handling the logout process for many websites:
http://www.the-art-of-web.com/system/safari-broken-logout/
http://bbpress.org/forums/topic/safari-cant-log-out
http://www.hostmonsterforum.com/showthread.php?t=5887
http://drupal.org/node/217482
It appears as though Safari is not consistent about refreshing credentials for 401 responses or HTTP Connection: Close.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10
I was unable to find related bugs in the database.
Attachments
A Fiddler trace (can be opened as a ZIP) demonstrating Safari's loop.
(736.27 KB, application/x-zip-compressed)
2009-10-02 17:56 PDT
,
Tim McConnell
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2009-08-13 16:50:32 PDT
Two of these links are about Safari 3, one is about cookie-based authentication, and one lacks any technical detail. That said, I do not quite understand what the first article (the most detailed) is talking about. Looks like the suggestion is to send 401 response when accessing a logout link - but that would result in an authentication dialog/sheet displayed in any browsers, won't it? That doesn't seem like acceptable UI anyway. What am I missing?
Alexey Proskuryakov
Comment 2
2009-08-13 16:54:11 PDT
And it is true that credentials aren't removed from credential storage when 401 is received. This code is new to Safari 4, as Safari 3 used a different implementation for credential storage.
Tim McConnell
Comment 3
2009-08-13 20:33:34 PDT
Thanks for the updates, Alexey. I apologize for the weak repro details, but I'm currently encountering these problems on internal sites that cannot be accessed from the internet. I'll continue to pursue a live repro.
Tim McConnell
Comment 4
2009-08-28 00:03:31 PDT
I believe that I have some more details. The problem is that Safari falls into a tight loop of sending a callback, receiving a 401, repeating the callback, receiving a 401 etc. in some logout cases. It looks like Safari does not handle the absence of the Negotiate token in the header when called through XMLHttpRequest object. This has the side effect that Safari will not show the Password Prompt, and then infinitely repeat its request to the box because the response is 0 bytes long.
Alexey Proskuryakov
Comment 5
2009-08-31 16:12:11 PDT
This sounds like a possible problem beneath WebKit, as authentication schemes themselves are implemented in closed source Apple code. In such case, this needs to be reported via
http://bugreport.apple.com
, but it's difficult to be sure without a test case or other hard data.
Tim McConnell
Comment 6
2009-10-02 17:56:30 PDT
Created
attachment 40560
[details]
A Fiddler trace (can be opened as a ZIP) demonstrating Safari's loop. Here's a Fiddler trace that contains the behavior in Safari when the 401 fails. It seems that having Safari Save Credentials will cause this bug to stop reproing. The server being tested for this trace (mainlatest) uses Windows NTLM integrated authentication.
Alexey Proskuryakov
Comment 7
2009-10-09 17:49:22 PDT
Could you please re-test with a nightly build <
http://nightly.webkit.org
> newer that 49410? There were some fixes to authentication behavior made recently, although I'm not holding my breath.
Tim McConnell
Comment 8
2010-01-13 11:06:42 PST
Alexey, this does appear to be fixed in 4.0.4, at least for the type of bug that we were seeing. I'll let you handle the final resolution steps. Thanks!
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