Zone d'administration accélérée (AMP) et zone d'administration protégée par mot de passe, puis-je combiner les deux en une seule page?
Site complet en cours de migration vers AMP. Je souhaite intégrer les fonctionnalités d'administration aux pages AMP, telles que des liens simples pour supprimer du contenu et des formulaires volumineux (non compatibles avec les appareils mobiles) permettant de modifier du contenu. Il sera visible après la connexion et le contenu non mobile sera dans les iframes (pour ne pas rompre le format AMP, car incompatible). En d’autres termes, je veux des pages uniques et identiques pour le front-end de l’utilisateur et de l’administrateur - les pages AMP, ce qui fonctionnera sur n’importe quel périphérique, et les mêmes pages AMP pour l’administrateur, ce qui nécessitera un écran de bureau, les actions de l’administrateur étant alors exécutées dans des fenêtres contextuelles ( iframes dans la visionneuse). Que dois-je faire pour que cela soit correctement fait:
- mot de passe protéger la version admin de la page - en d'autres termes, la page sera différente en fonction du cookie de session,
- créer des liens absolus vers les éléments de l’administrateur, non relatifs, avec une URL complète incluant mon domaine, afin d’éviter le contenu mis en cache par hit? Google modifie-t-il les liens relatifs lors de la mise en cache d'AMP ou ne le touche-t-il pas du tout?
- Créer des en-têtes différents, autorisant la page de cache par en-têtes avec le contenu de l'utilisateur (et le formulaire de connexion), et désactivant le cache par en-têtes http pour l'administrateur connecté? Est-ce vraiment nécessaire?
Quelque chose me manque? Cela fonctionnera-t-il comme prévu? Est-ce un bon moyen, dans le cas où un domaine administratif distinct ne mérite pas d'être développé et n'est pas souhaitable?
Google utilisera-t-il les pages de cache dans le cache AMP même en empêchant les en-têtes de contrôle du cache? Différents en-têtes de contrôle du cache sont-ils nécessaires pour la page par défaut et pour la page "connectée"?
Les pages de l'interface utilisateur administrative et les pages qui ne doivent pas être stockées dans le cache n'ont tout simplement pas l'attribut ou amp dans la balise html, tout en utilisant les javascripts et les balises amp. Quoi qu'il en soit, ces pages peuvent être protégées par un mot de passe et cachées du cache du robot et de l'ampli. L'interface utilisateur dynamique ne doit pas être mise en cache. Cela diffère de l'envoi d'en-têtes de contrôle du cache, car les pages dont les en-têtes ont déjà expiré peuvent toujours être servies à partir du cache d'amplis.
"[le cache] utilise les en-têtes de mise en cache de l'origine, tels que Max-Age, pour indiquer si un document ou une ressource est obsolète. Lorsqu'un utilisateur fait une demande pour quelque chose qui est obsolète, cette demande entraîne la création d'une nouvelle copie. récupéré, de sorte que le prochain utilisateur obtienne un nouveau contenu "
Le cache est autorisé à servir du contenu obsolète indépendamment des en-têtes de mise en cache HTTP. Il doit déployer des efforts raisonnables pour conserver le contenu du cache à jour et revalider le contenu après avoir envoyé des réponses obsolètes.
Le retrait de amp rend l’ampère non valide, mais n’utilise toujours que peu d’avantages. Toutefois, les pages statiques ou peu modifiées doivent toujours être en cache, ce qui présente de nombreux avantages, tels que le pré-rendu, les images redimensionnées pour différents périphériques, minified html/js/css.
Référence: https://github.com/ampproject/amphtml/blob/master/spec/amp-cache-guidelines.md
Update : le cache AMP remplace tous les liens sortants. Ainsi, par exemple: le lien vers une image ou une page mise en cache pointe vers le cache CDN, mais ce lien, par exemple, ne pas mettre en cache la page de connexion sera une URL complète vers le domaine du site, pas le CDN - même le lien/le formulaire de connexion provient du cache CDN.
Les mêmes pages ne peuvent pas être à la fois une version régulière et une version non mise en cache de l'administrateur, car une version régulière peut s'installer dans le cache de l'amplificateur, le cache du navigateur et l'administrateur connecté verra la page du cache, à la place de sa version non mise en cache. Cependant, il est possible d’ajouter un préfixe aux pages, comme "/ admin_" par mod_rewrite, pointant vers le même code, mais ce code renverra une page pour cache ou une page non pouvant être mise en cache avec des addons d’administrateur, en fonction du préfixe.
Il semble également possible d’utiliser un cookie administrateur au lieu du préfixe, selon les règles suivantes: redirection de connexion vers l’url du site, pas avec cdn. Les scripts renvoient la version non cacheable avec l'interface utilisateur administrative en fonction du cookie. Les mêmes scripts renvoient la version cacheable si aucun cookie n'est présent. Les en-têtes de contrôle du cache permettent au navigateur de revalider à chaque fois la version en cache. semble perdre certains avantages du cache, par rapport à la version avec le préfixe "admin".