Bonjour,
Pour le contexte : je travaille sur une suite applicative composé de plusieurs outils :
Une mire de connexion sous un nom de domaine typiquement manager . example . com
Une application du style modulea . example . com
Une autre application du style moduleb . example . com
Par défaut toutes les pages de toutes les applications redirige vers manager.example.com/connexion et renvoie un cookie qui sert d’authentification sur tous les sites (avec un sso derrière).
Le problème est que j’ai vu qu’asqatasun ne gère que sur un nom de domaine, du coup est-ce que c’est possible de gérer le multi application sur “example.com” malgré qu’il va y avoir plusieurs noms de sous domaines ?
De plus, est-il possible de techniquement inclure ce cookie pour toute la navigation (dans le crawler ou autre) ?
Merci
ps : j’ai mis des espaces dans les noms de domaine car c’est limité à 2 lien pour les nouveaux utilisateurs
Merci pour ta question intéressante. Je vois plusieurs niveau de réponse.
Les scénarios permettent de suivre un parcours utilisateur, et donc de sauter de domaine en domaine. Mais la constitution du scénario risque d’être un peu longuette.
En parallèle, j’imagine que tes modules sont utilisables “différemment” lors de leur construction. J’imagine une chaine d’intégration avec des tests, je me dis que les dev bossant dessus ont dû dégager ou simplifier l’autentification. C’est à ce moment / cet endroit qu’il faudra taper. En plus tu te rapproche des dév, encore plus efficace pour corriger d’éventuelles coquilles d’accessibilité.
Enfin, sous l’angle de la chaine d’intégration continue (CI), tu peux aussi valoriser l’API d’Asqatasun pour produire un job qui produit juste du rouge ou du vert en présence (resp. absence) d’erreurs.
Peut-êtr @koj aura d’autres idées différentes des miennes.
Oui on a pensé à la solution des scénarios mais pas facile à maintenir au quotidien pour les équipes.
Pour les tests on a plusieurs cas:
une équipe dédiée aux tests fonctionnelles qui gère ça avec du robot framework et des scénarios codés mais non utilisable dans ce cas la, et ils n’auront pas le temps de gérer les scénarios pour Asqatasun en plus.
une solution qu’on utilise en général c’est la génération d’un cookie “dev” contenant un mock d’un utilisateur qui est libre d’aller sur toutes les pages, mais pour utiliser ce cooker il faudrait l’intégrer dans le crawler.
Je travaille justement en tant que DevOps sur la CI/CD donc l’utilisation d’une API pourrait être la solution, il y a t-il une documentation de cette API ?
Tout d’abord merci pour l’intérêt porté à Asqatasun et le cas d’usage très intéressant qu’il s’agit d’essayer d’adresser.
Pour compléter la réponse de Matthieu, effectivement le chemin le plus court aurait été l’usage des scenarios, mais cela aurait été trop facile.
Pour ce qui est de gérer les sous domaine de “example.com”, il me semble que le composant crawler permet déjà d’accepter les sous-domaines. Il faudrait tester avec un cas d’usage concret. Mais à priori, ici, je ne vois pas de barrière technique. Tu as déja pu essayer de ton coté? Qu’est ce que tu constates?
Pour ce qui est du cookie, les 2 composants de l’application qui parcourent le site (module crawler chargé de récupérer la liste des pages à auditer et le module loader chargé de monter la page en contexte navigateur) offrent la possibilité d’inclure des cookies dans leurs requêtes à travers leur API.
Cela nécessite d’implémenter une petite évolution, mais elle me semble tout à fait pertinente et elle va dans le sens de favoriser le déploiement en répondant au maximum de cas d’usage (et dieu sait qu’ils sont nombreux)
En espérant que cela puisse te permettre d’avancer
