Safari 5.1 and HTTP basic access authentication not working

Question

Level 1

10 points

Safari 5.1 and HTTP basic access authentication not working

After upgrading to Mac OS X Lion, Safari 5.1 appears to not behave correctly with HTTP basic access authentication and server page redirects. Safari 5.1 is prompting for the username and password again on pages protected by HTTP basic access authentication, but only if those pages are the result of the server sending a 301 or 302 header to redirect to that page. Previous versions of Safari, and all othe current web browsers, do not prompt for the password again. I have confirmed this problem on three separate Macs running Safari 5.1.

A sample workflow:

In Safari 5.1, visit a web site with HTTP basic access authentication in place
HTTP basic access authentication can be configured on an Apache web server using directives such as "AuthType Basic" and "Require valid-user" either within the main server's configuration or inside a .htaccess file. It's typically used in conjunction with a .htpasswd file.
Safari presents a sheet window asking for a username and password
This only appears if it's the first time visiting the site since opening Safari. Log in with the username and password, click "Log in," and the page loads.
Click a link to a regular page on the site
The page loads. There's no re-entry of username and password required as expected.
Click a link to a page that sends a 301 or 302 "moved" header to redirect the browser to another page
The sheet window appears in Safari asking for the username and password again.

This behavior is incorrect.

For reference, Safari's "AutoFill web forms" is checked in the Preferences window; however, I do not check the "Remember this password in my keychain" checkbox in the sheet window Safari produces to enter the username and password for HTTP basic access authentication.

Oddly, a lot of my day-to-day web development has this scenario which renders Safari 5.1 unusable at this time. I have been unable to find anyone else mentioning this issue.

Has anyone else also noticed this?

Safari-OTHER, Mac OS X (10.7)

Posted on Aug 19, 2011 11:14 AM

Reply

Answer 1

Aug 26, 2011 3:00 AM in response to Enjolras

Yes, I am experiencing this a lot also. I think hardly anyone has noticed it because its a fairly specific set of circumstances. I find it particularly annoying as our company-developed CMS uses HTTP-Auth and redirects a lot. So I have to reauth on every update.

Have you found a solution to this, or had any responses from anyone?

Reply

Answer 2

Aug 26, 2011 11:13 AM in response to Enjolras

Enjolras

I was having the same issue with Safari 5.1 update on Snow Leopard, oddly I did not have this issue on a Lion upgrade from SL on my MBP.

I was able to resolve the issue by unchecking "User names and passwords" in the Auto fill portion of Safari's preferences. Quiting Safari, and then opening Safari again and then checking the "User names and passwords" option. Returning to the authentication page resulted in my user names and passwords returning to their auto fill simplicity.

Results may very, but I hope this can help.

Nick

Reply

Answer 3

Aug 26, 2011 11:53 AM in response to Enjolras

Yes! That was happening to me with Facebook! I was wondering why that was happening. I use Snow Leopard but ever since updating to Safari 5.1 my Java doesn't work and I have been having odd behavior such as what you mentioned in your post. Ugh

Reply

Answer 4

mike.l.r

Level 1

0 points

Sep 29, 2011 1:20 AM in response to Enjolras

Yep, having the exact same problem, and it's really annoying. Looking at the HTTP headers, it is definitely because of the 30x redirection. I've compared it against Firefox, and Safari is not sending the "Authorization: Basic" HTTP header with the authentication credentials in the GET directly after the 30x notification from the server. Because it's not getting the credentials, the server needs to get the client to reauthenticate. On normal GETs, Safari sends the Authorization header as expected. It only happens on a redirect.

I'm just wondering if it's related to this: http://lists.apple.com/archives/Webkitsdk-dev/2011/Mar/msg00006.html. Instead of fixing it, maybe they just stopped sending authorizations altogether on redirects.

I'm going to submit a bug report to Apple via the Safari "Report Bugs to Apple..." thingy. Fingers crossed it's fixed in an update shortly.

Reply

Answer 5

Enjolras Author

Level 1

10 points

Oct 12, 2011 8:05 PM in response to mike.l.r

It looks like today's release of Safari 5.1.1, which was included in the Mac OS X 10.7.2 update, has resolved this issue!

Reply

Answer 6

Enjolras Author

Level 1

10 points

Oct 17, 2011 3:25 PM in response to Enjolras

Correction—the problem still exists. It was not resolved by Safari 5.1.1.

Reply

Answer 7

Oct 19, 2011 2:23 AM in response to Enjolras

I send a bugreport to apple about a very similar issue:

http://www.openradar.me/9976744

Reply

Answer 8

dozy

Level 1

19 points

Oct 31, 2011 12:49 PM in response to Enjolras

I'm getting this, too, using Safari 5.1.1. Thought it was my code, but found it was Safari. Unfortunately makes my web development impossible on Safari.

Reply

Answer 9

worksafe

Level 2

180 points

Oct 31, 2011 2:01 PM in response to dozy

First I Reset Safari, then close Safari then navigate to:

Home/Library/Preferences and look for and then remove

com.apple.Safari.plist

com.apple.Safari.RSS.plist

Also:

Home/Library/Safari/ folder and remove the following two files:

history.plist

lastsession.plist

And

Go to Home/Library/Caches/Metadata/Safari/ and remove the contents of that folder.

(These are just webhistory files and are not required for Safari to run. However, similar to preference files, problems can arise if they have become corrupt.)

Locate the cookies.plist file that's located in the Home/Library/Cookies/ folder and remove it.

They will all be recreated next time you launch Safari.

Reply

Answer 10

Enjolras Author

Level 1

10 points

Oct 31, 2011 2:07 PM in response to worksafe

You didn't say—does this resolve this particular problem? How is this different from using the "Reset Safari..." or "Empty Cache..." features built in to Safari?

Reply

Answer 11

Nov 13, 2011 4:48 PM in response to Enjolras

no, it doesn't resolve the problem 😟

Reply

Answer 12

Jan 13, 2012 1:50 PM in response to Enjolras

I'm having this problem with Safari and an osCommerce store that I have behind http authentication. Does anyone know if this bug has been reported to Apple other than here?

Reply

Answer 13

mike.l.r

Level 1

0 points

Jan 13, 2012 3:08 PM in response to stevengking

Yeah, I raised a bug report through the Safari "Report bugs to Apple..." menu item. That was a couple of months ago, and Safari has been updated once or twice since then with no fix. Of course, I got no feedback on my report. I guess if more people submit reports on this issue, it might get fixed.

Reply

Answer 14

Jan 17, 2012 3:21 AM in response to Enjolras

Yes. I'm having a similar issue. I'm using Filemaker Pro's Web Viewer feature which uses the Safari webkit to render webpages in layouts and as it's dependent on Safari's settings, I'm having all sorts of problems with basic authentication.

Reply

Answer 15

tb06

Level 1

8 points

Feb 16, 2012 1:03 PM in response to Enjolras

I've seen this, too, consistently since the Lion upgrade. Safari 5.1.1 has not fixed it. I see this without a 301 or 302 redirect involved in accessing the page. It is extremely frustrating! The AutoFill lilsted below did not help in my case.

Reply