Базовая HTTP-аутентификация QuickTime в Safari 4

Я использую Mac OS X Leopard 10.5.8 с Safari 4.0.3. В моем кросс-платформенном Java-приложении есть встроенный собственный веб-браузер с собственным внутренним веб-сервером. Всякий раз, когда браузер пытается обслуживать файл, который требует quicktime (mov, mp4, m4v и т. д.), я получаю диалоговое окно с учетными данными имени пользователя/пароля. Я вижу каждый запрос, проходящий и аутентифицируемый (по крайней мере, html-файл аутентифицируется) ... затем я вижу, например, запрос на mp4, и он никогда не аутентифицируется. Это почти так же, как если бы QuickTime никогда не передавал учетные данные и не пытался аутентифицироваться сам по себе.

Я сам передаю эти учетные данные, и любой другой тип файла отлично работает с базовой аутентификацией. Я даже могу запустить приложение в Windows с QuickTime 7.6.4 и точно такими же файлами, и они воспроизводятся, как и ожидалось (в данном случае Windows использует IE8 в качестве встроенного браузера).

Известны ли проблемы с QuickTime 7.6.4 и базовой проверкой подлинности в Safari 4? Я искал немного в Интернете без везения.


macos java basic-authentication quicktime
person KKlucznik    schedule 19.10.2009    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Это не проблема Safari 4, а проблема QuickTime 7.6.4. Дополнительные меры «безопасности», которые были включены в эту версию, заставляют сам QuickTime аутентифицироваться. Хотя запрос от браузера к моему серверу для файла html и mp4, например, удовлетворяется учетными данными, которые я предоставляю ... другой запрос учетных данных генерируется после того, как QuickTime. я не могу заполнить эти учетные данные, поскольку прослушиватель аутентификации является частью браузера, а событие запускается из QuickTime.

Мой обходной путь для этого второго набора учетных данных был найден при анализе заголовков запроса. Я обнаружил, что когда QuickTime делал запрос из моего приложения, путь к файлу в заголовке GET был относительным путем, потому что базовый путь был известен веб-серверу. Когда тот же запрос был сделан из QuickTime с использованием параметра «Открыть URL» в меню «Файл», весь абсолютный путь к файлу был в заголовке GET. Затем я мог бы проверить этот заголовок GET и, если бы у него был абсолютный путь, этот запрос исходил из внешнего источника и требовал учетных данных, в противном случае он исходил из моего приложения, и базовая аутентификация не требуется.

person KKlucznik    schedule 03.11.2009