10
votes

HTML5 Manifest cache derrière l'autorité de base?

J'ai un site qui utilise HTML5 Caching et qui travaille bien.

Lorsque je protège le site à l'aide de l'authentification de base (.htpasswd) La mise en cache ne semble pas fonctionner. Idéalement, j'aimerais que le site se cache pour des utilisateurs authentifiés. Ma théorie est que, lorsqu'ils visitent le site hors ligne, le serveur n'est pas en train d'être touché et la version mise en cache est affichée.

Cela fait-il partie de la spécification HTML5 que les pages ne sont pas cachées si elles sont protégées? Je ne pouvais trouver aucune référence à cela.

Quelqu'un a-t-il créé avec succès une application macabotable protégée par mot de passe?

Je ne sais pas si cela est spécifique au navigateur mais je teste dans Safari - c'est une application iPad.

Merci d'avance


0 commentaires

3 Réponses :


1
votes

J'ai eu ce même problème. L'authentification a cassé ou désactivé le JS sur la page qui a lancé le manifeste de cache lorsque nous avons lancé l'application en mode plein écran à partir de l'écran d'accueil.

En tant que travail autour, de mobile Safari, nous enregistrons une page à l'écran d'accueil qui est une version dupliquée de la page que nous voulons que notre manifeste de cache fonctionne. Ensuite, une fois que vous avez lancé la page à partir de l'écran d'accueil, nous transférons la page dupliquée à la page réelle que nous exécutons le cache manifeste de.

Ceci invite la connexion mais ne casse pas le JS exécutant le manifeste de cache puisqu'il est techniquement invitée à notre "fausse page" si l'utilisateur est ensuite immédiatement transféré à la bonne page où leur téléchargement de cache commence alors avec succès.

Cela semble être un bogue dans le mode plein écran de safari mobile. Espérons que de telles choses seront corrigées dans une version future. J'espère que cela aide.


mise à jour: Le correctif ci-dessus n'a pas fini de fonctionner pour nous car la fausse page introduction n'est pas incluse dans le manifeste, de sorte qu'il ne se charge pas une fois hors ligne. un bummer. Nous avons fini simplement à initier la mise en cache du safari mobile, de sorte que toutes les mises à jour prises doivent être effectuées via le navigateur et non en mode plein écran.


0 commentaires

4
votes

Certaines autres personnes se plaignaient du même problème sur iOS 3.x et a déclaré déplacer le fichier manifeste en dehors du répertoire authentifié semblant corriger les choses: http://lists.apple.com/archives /safari-iphone-web-dev/2010/sep/msg00000.html

J'ai pu contourner le problème avec un fichier .htaccess dans le dossier en question qui ressemblait à ceci: xxx


2 commentaires

Nous avons dû ajouter satisfaire tout au Michelch (code> Groupe pour faire ce travail.


Quelqu'un peut-il confirmer que l'utilisation de l'authentification de base en mode hors connexion fonctionne avec le dernier safari?



10
votes

Ceci est effectivement causé par Cors car le navigateur traite La demande en tant qu'ordre croisée.

Une bonne solution consiste à ajouter crossorigin = 'user-Credentials' sur votre définition manifeste, comme: xxx

Ceci transmettra ensuite vos informations d'identification sur la demande manifeste.

Plus d'infos sur ce paramètre :: https://developer.mozilla.org/en-us/docs/web/html/cors_settings_attributes


1 commentaires

C'est la bonne réponse, voir: Github.com/w3c/manifest/issues/535