Authentification de base HTTP QuickTime sur Safari 4

Question

J'utilise Mac OS X Leopard 10.5.8, qui exécute Safari 4.0.3. Mon application Java multiplateforme dispose d'un navigateur Web natif intégré avec son propre serveur Web interne. Chaque fois que le navigateur essaie de servir un fichier qui a besoin de quicktime (mov, mp4, m4v, etc), j'obtiens une boîte de dialogue de nom d'utilisateur/mot de passe. Je peux voir chaque requête passer et s'authentifier (au moins le fichier html est authentifié) ... puis je vois la requête pour le mp4 par exemple et il ne s'authentifie jamais. C'est à peu près comme si QuickTime ne transmettait jamais les informations d'identification et essayait de s'authentifier par lui-même.

Je transmets ces informations d'identification en interne et tous les autres types de fichiers fonctionnent correctement avec l'authentification de base. Je peux même exécuter l'application sur Windows avec QuickTime 7.6.4 et les mêmes fichiers exacts et ils jouent comme prévu (Windows utilise IE8 comme navigateur intégré dans ce cas).

Y at-il des problèmes connus avec QuickTime 7.6.4 et l'authentification de base sur Safari 4? J'ai cherché un peu en ligne sans aucune chance.

Answer 1

Ce n'est pas un problème avec Safari 4, mais un problème avec QuickTime 7.6.4. Les mesures de sécurité ajoutées dans cette version entraînent l'authentification de QuickTime. Bien que la demande du navigateur à mon serveur pour le fichier html et le mp4 par exemple sont satisfaits avec les informations d'identification que je fournis ... une autre demande d'informations d'identification est générée après par QuickTime. Je ne peux pas remplir ces informations d'identification avec l'écouteur d'authentification faisant partie du navigateur et l'événement étant déclenché à partir de QuickTime.

Mon travail autour de ce deuxième ensemble d'informations d'identification a été trouvé dans l'analyse des en-têtes de demande. J'ai trouvé que lorsque QuickTime faisait une requête à partir de mon application, le chemin d'accès au fichier dans l'en-tête GET était un chemin relatif car le chemin de base était connu par le serveur web. Lorsque la même requête a été effectuée à partir de QuickTime à l'aide de l'option "Ouvrir une URL" dans le menu Fichier, le chemin absolu entier du fichier se trouvait dans l'en-tête GET. Je pourrais alors vérifier cet en-tête GET et s'il avait un chemin absolu cette demande provenait d'une source extérieure et exige des informations d'identification, sinon elle provenait de mon application et aucune authentification de base n'est nécessaire.