Oak Configuration de jeton de connexion

Question

Je suis confronté à un problème dans AEM6.1 où les utilisateurs ont un jeton de connexion invalide (en raison d'une session expirée). Ils font une demande à l'auteur d'AEM qui a alors une erreur parce qu'ils sont fondamentalement un utilisateur anonyme essayant d'afficher une page. Le problème d'accès entraîne un 404. La page d'erreur ACS tente de le gérer, mais la page d'erreur comme tout le reste sur l'auteur n'est pas lisible par un utilisateur anonyme. Donc, il a une exception Java, et l'utilisateur est laissé avec un écran blanc de la mort

Les cookies de connexion-jeton dans le navigateur n'ont pas d'expiration. Ils semblent être configurés pour rester jusqu'à ce que la session soit fermée par les utilisateurs. Je voudrais définir l'expiration sur les cookies de connexion-jeton. Je fais des recherches mais je ne vois pas comment cela est fait. Le site aemstuff http://www.aemstuff.com/#article964 pointe vers «Apache Jackrabbit Oak TokenConfiguration». Mais cela a déjà été défini sur 43200000, et d'autres modifications n'affectent pas l'expiration du cookie de connexion autant que je peux le voir.

Ma question pour SO est; existe-t-il un moyen de définir l'expiration du jeton de connexion sur le cookie? Cela ressemble à un bug avec "Apache Jackrabbit Oak TokenConfiguration" ou est-ce?

Answer 1

Créez Apache Jackrabbit Oak TokenConfiguration en tant que nœud de configuration.

Answer 2

Dans d'autres cas confrontés à des problèmes similaires, voici quelques-unes des choses que j'appris sur ce

• expiration de connexion jeton peut être configuré comme suggéré par Disha. Il est utilisé uniquement sur le backend. Je pense que c'est très typique pour les cookies de session de navigateur pour ne pas avoir le jeu d'expiration.
• Le problème WSOD peut avoir été résolu en ajustant ce délai d'attente de session légèrement inférieur au délai IDP
• Je pense qu'il est très important d'utiliser Java 8 avec AEM6.1 et peut-être d'autres versions. Lorsque nous avons mis à jour AEM6, Java 7 est resté notre version en cours d'exécution. Il est possible que SAML SSO utilise Java 8 choses. Après avoir passé à Java 8, les utilisateurs n'ont plus jamais eu le WSOD.