2017-02-16 10 views
0

Nous utilisons la fonction HTML5 cache de l'application:HTTP Strict Transport Security et HTML5 cache de l'application

<html manifest=".appcache"> 
    ... 
</html> 

Lorsque les utilisateurs reviennent naviguer à cette application, ils ont déjà tous les fichiers statiques mis en cache et l'application est donc chargée sans demandes de réseau. Une fois l'application chargée, AJAX demandera de charger le contenu dynamique et le navigateur vérifiera si le manifeste du cache d'application est obsolète et éventuellement télécharger une nouvelle version de l'application en arrière-plan.

Beaucoup de nos utilisateurs accèdent cette application de connexions non sécurisées (HTTP, HTTPS non).

Nous sommes en train d'introduire HTTP Strict Transport Security (HSTS Les) sur les serveurs qui hébergent l'application.

mise en œuvre HSTS signifie que nos serveurs vont gérer les requêtes comme celle-ci:

  • Si la demande est non sécurisée (HTTP uniquement), le serveur répondra avec l'état HTTP 301 et un en-tête Location qui redirigent la URI demandé mais en changeant le schéma à https.

  • Dans le cas contraire; Si la requête est sécurisée (HTTPS), le serveur la traitera normalement mais décore la réponse avec un en-tête Strict-Transport-Security.

Ainsi, lorsqu'un nouvel utilisateur d'ouvrir notre application sur HTTP, ils seront redirigés vers HTTPS au lieu et le cache manifeste d'application est installé en utilisant l'emplacement sécurisé. C'est parfait.

Cependant, un utilisateur de retour (sur HTTP) ne sera pas redirigé vers l'endroit sûr (parce qu'ils ont déjà une version en cache sur l'emplacement non sécurisé). Le manifeste du cache de l'application ne se chargera pas (puisqu'il s'agit d'une redirection). Les utilisateurs qui reviennent sont donc bloqués avec la version de l'application qu'ils ont mise en cache et ils sont bloqués en utilisant HTTP, ce qui n'est plus autorisé. C'est très mauvais.

Nous avons besoin de trouver un moyen de transition retour HTTP utilisateurs vers la version HTTPS. Comment serait-il préférable de faire cela?

La façon dont je le vois, il y a deux problèmes:

  1. Le navigateur ne peut pas chercher le manifeste d'application (parce qu'il est une redirection). Il est donc impossible de mettre à niveau l'application vers une nouvelle version.

    On pourrait peut-être résoudre ce problème en configurant nos serveurs pour permettre /.appcache à desservir par simple HTTP.

  2. Même si nous faisons cela, l'application sera toujours accessible à l'emplacement HTTP (depuis que ce qui est mis en mémoire cache par le manifeste)

    Pour contourner cela, nous pourrions avoir à mettre en œuvre une sorte de javascript logique qui change le schéma de document.location.href à HTTPS.

    Je n'aime pas cette approche, mais c'est la seule que nous avons à ce stade.

Répondre

0

Nous avons retenu la solution suivante à ce problème:

Lorsque le serveur reçoit une demande non sécurisé pour obtenir le cache de l'application manifeste (/.appcache dans notre cas), alors une réponse 404 est retourné au lieu de la redirection HTTPS normale (301).

Obtenir une 404 provoque le manifeste d'être mis en mémoire cache rassis et le navigateur tentera donc de recharger l'application sur la prochaine mise à jour, qui le fera à récupérer index.html et être redirigé vers l'emplacement sécurisé.