Home/ Questions/Q 432751
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T20:06:21+00:00

I am using Mac OS X Leopard 10.5.8, which is running Safari 4.0.3. My

  • 0

I am using Mac OS X Leopard 10.5.8, which is running Safari 4.0.3. My cross platform Java app has an embedded native web browser with its own internal web server. Whenever the browser tries to serve up a file that needs quicktime (mov, mp4, m4v, etc) i get a username/password credential dialog. I can see every request coming through and getting authenticated (at least the html file is authenticated)…then i see the request for the mp4 for example and it never gets authenticated. Its pretty much as if QuickTime is never handing the credentials over and trying to authenticate by itself.

I internally pass these credentials myself and every other file type works fine with basic auth. I can even run the app on Windows with QuickTime 7.6.4 and the same exact files and they play as expected (Windows is running IE8 as the embedded browser in this case).

Are there known issues with QuickTime 7.6.4 and basic authentication on Safari 4? I searched a little online with no luck.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is not an issue with Safari 4, but an issue with QuickTime 7.6.4. The added “security” measures that were put into this version cause QuickTime itself to authenticate. Although the request from the browser to my server for the html file and the mp4 for instance are satisfied with credentials i provide…another request for credentials gets generated after by QuickTime. i cannot fill in these credentials with the authentication listener being part of the browser and the event being fired from QuickTime.

    My work around for this second set of credentials was found in analyzing the request headers. I found that when QuickTime was making a request from within my app, the path to the file in the GET header was a relative path cause the base path was known by the web server. When the same request was made from QuickTime using the “Open URL” option in the File menu, the entire absolute path to the file was in the GET header. I could then check this GET header and if it had an absolute path this request was coming from an outside source and requires credentials, otherwise it was coming from my app and no basic authentication is needed.

    • 0