Currently Being ModeratedFeb 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.
Currently Being ModeratedMar 1, 2012 7:28 AM (in response to Enjolras)
The issue I just posted seems to be related to the problem you describe:
I was able to reproduce an issue using the HTML 5 audio tag and the drupal_goto method in Drupal. In both cases, in Safari 5.0.5 and Safari 5.1.2, in the apache logs, the initial requests to the page include the authenticated user, but the request to download the audio file or the request to go to a new page somehow did not send the authentication information because the request in the log doesn't include anything.
So for example, I am authenticated by apache and submit a form. The page processes the form then uses drupal_goto to redierct to another page. From Chrome, the following appears in the apache log:
::1 - tom [02/Feb/2012:17:23:46 -0500] "POST /drupal/node/6?q=node/6 HTTP/1.1" 302 502
::1 - tom [02/Feb/2012:17:23:46 -0500] "GET /drupal/node/8 HTTP/1.1" 200 3019
When I do the same thing in Safari:
::1 - tom [02/Feb/2012:17:25:50 -0500] "POST /drupal/node/6?q=node/6 HTTP/1.1" 302 502
::1 - - [02/Feb/2012:17:25:50 -0500] "GET /drupal/node/8 HTTP/1.1" 401 401
::1 - tom [02/Feb/2012:17:25:55 -0500] "GET /drupal/node/8 HTTP/1.1" 200 3019
The request after the goto doesn't include authentication information - and I have to put in my username and password.
This is an annoyance in the case of redirection - having to reauthenticate every time - but in the case of HTML 5 audio it is fatal. The audio file specified in the source tag simply does not load.
Currently Being ModeratedMar 12, 2012 1:28 PM (in response to Enjolras)
Today, Apple released Safari 5.1.4. This problem is still not resolved.
Currently Being ModeratedJul 26, 2012 3:47 AM (in response to Enjolras)
Looks like it's fixed in Safari 6. Finally.
Currently Being ModeratedSep 1, 2012 1:06 PM (in response to mike.l.r)
Nope. Not fixed in Safari 6. It is very anoying to have to keep logging in twice.
Currently Being ModeratedSep 1, 2012 4:46 PM (in response to chgobearmike)
Weird, it's most definitely working for me now. Tested on three different computers (Lion and Mountain Lion): the webpage login details are not in Keychain and on basic 301, 302, 303 and 307 redirects the "Authorization:Basic" is included in the redirected HTTP header as expected, so I am not getting a second login prompt. That was not happening before Safari 6.
Currently Being ModeratedNov 19, 2012 1:31 PM (in response to Enjolras)
I have a FileMaker developer for my company and this bug is affecting all of my FileMaker users. Users are now being required to repeatedly authenticate for tasks that previously required no authentication (because it was stored in the computers' keychain).
Currently Being ModeratedFeb 21, 2013 10:25 PM (in response to Enjolras)
I am also having this problem. Extremely frustrating! Introduced with an upgrade to Mountain Lion. Will this ever be fixed?
Currently Being ModeratedApr 19, 2013 11:02 AM (in response to Enjolras)
Installed Safari 6.0.4 today and the problem is *still* there. Works as expected in FF and Chrome. Does anyone know of a workaround that doesn't require moving the video to an unprotected directory?
Currently Being ModeratedMay 27, 2013 12:25 AM (in response to terryb)
Happy to see that it's not my code is not the cause of the problem.
One possibility to escape to this bug under Safari, might be to generate a time-limited link, and this only if the user it is authenticated on the page. I'm using PHP, so I should be able to obtain a fix with "PHP_AUTH_USER" or similar.
I'm not really expecting that Apple will correct it...
Currently Being ModeratedOct 25, 2013 7:03 AM (in response to Enjolras)
Filemaker 12.05, Mavericks, this still exists! Has anyone heard any news on this, or are both companies silent on the matter?
Currently Being ModeratedJan 13, 2014 2:24 AM (in response to Enjolras)
i can confirm this bug on safari 6.1. also a lot of customer complaints, different versions. have to switch our web app's auth mechanism. I don't expect apple to fix this as it seems to exist since some years!!