Bonjour,
Je viens de migrer une 3.2 en 5.1. Je viens de m’apercevoir que les zones web ne sont plus présentes.
Comment puis-je personnaliser la page d’authentification ?
En 4.0+ ça se gère via des ressources. Ex: LOGON_ADDON pour ajoutre un bloc sous le formulaire de logon:
Resultat:
Merci pour les informations.
Super cette version !
1 Like
Bonsoir David,
ça répond parfaitement à un besoin que j’ai d’informer mes utilisateurs du traitement de leurs données personnelles (dès le logon) mais ça ne fonctionne pas sur l’instance 5.1.5 https://bcsidev.renault.simplicite.io/
Cette page de logon n’a-t-elle pas été customisée ?
Testé sur une 5.1 à jour “out of the box”:
avec:
ça je comprends mais je ne sais pas où ça se trouve…
je n’ai touché à rien de ce côté (
)
J’ai trouvé!
J’utilise encore l’ancien paramètre système “AUTH_PROVIDERS” (ancêtre de “AUTH_PROVIDER”).
Avec le nouveau paramétrage, ça fonctionne.
Par contre, je dois vérifier que tout continue de fonctionner avec cette nouvelle configuration (calls API avec un token renault & co.).
La question de la modification d’un paramètre du module système se pose aussi : Je dois soit appliquer les éventuelles modifications de ce paramètre en tant que designer si je veux conserver la protection des modules systèmes lors de nos livraisons soit déplacer ce paramètre dans un de nos modules.
Perso je ne déplace jamais les trucs systèmes dans un module métier.
Les params système ont désormais un sys_value2 qui sert à les surcharger localement genre:
<?xml version="1.0" encoding="UTF-8"?>
<simplicite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.simplicite.fr/base" xsi:schemaLocation="http://www.simplicite.fr/base https://www.simplicite.io/resources/schemas/base.xsd">
<object>
<name>SystemParam</name>
<action>update</action>
<data>
<sys_code>XXX</sys_code>
<sys_value2>xxx</sys_value2>
</object>
</simplicite>
C’est la bonne manière de faire mais ça ne se package pas - encore - dans un module (à noter qu’on ne livre jamais de sys_value2 dans les modules et patches système).
NB: Pour certains param système pas trop “bas niveau”, une surcharge par un param de disposition associé à la disposition “default” est une autre approche (et celle-ci s’exporte dans le module)
1 Like
C’est bon avec un paramètre de disposition (défini sur la disposition default).
J’ai restauré le paramètre système à son état initial (sans surcharge de valeur) et le paramètre de disposition semble être utilisé.
Merci encore pour ton support.
OK super.
Confirme moi si ça ne pose pas de pb à l’authent via token externe sur le endpoint API, cette partie du code reste très marquée par le mode “mono-provider IdP” de l’époque.
Bon, j’ai testé de notre côté et avec la nouvelle conf “AUTH_PROVIDERS”, impossible de créer une session API avec un token valide (réponse “Invalid token”).
En restaurant l’ancien paramétrage “OAUTH2_PROVIDER” (+clear cache) ça refonctionne immédiatement.
Testé sur un build Version=5.1.3 BuiltOn=2021-09-23 13:33.
OK nous allons investiguer car cette partie du code date (et ne sait gérer qu’un seul provider externe).
PS: Peux tu m’envoyer en message privé un exemple de token JWT issu de votre IdP et utilisé sur le endpoint API
Merci…
Autre point: en activant les deux (OAUTH2_PROVIDER et AUTH_PROVIDERS) j’arrive à cumuler les deux aspects voulus (prise en compte de LOGON_PROVIDERS_ADDON et le login API avec token externe).
Donc, pour l’instant, si le nouveau paramètre AUTH_PROVIDERS ne remplace pas encore le précédent paramètre OAUTH2_PROVIDER, il ne l’invalide pas non plus.
Les params <OAUTH2|SAML|..>_PROVIDER ne sont plus supportés mais on les a conservés comme “fallback” uniquement pour laisser le temps aux designers de faire la conversion vers AUTH_PROVIDERS.
Sur le endpoint API la logique d’authent est différente et il doit y avoir une préséance erronée de ce coté. Cette partie du code a besoin d’un “lifting” de toute façon (ex: si possible exploiter les données du payload JWT pour identifier le provider, actuellement dans le doute un token externe est considéré comme un “dummy token” sur ce endpoint)
Autrement dit le fait que ça marche actuellement avec les 2 types de paramètre (AUTH_PROVIDERS sur UI et OAUTH2_PROVIDER sur API) relève donc d’un heureux hasard qui ne durera pas.
Je pense que j’ai trouvé : le paramètre de la disposition default permettant de surcharger le paramètre système AUTH_PROVIDERS n’est pas pris en compte via le endpoint API. Si je remonte la conf dans le paramètre système, le call API fonctionne avec le token externe fourni…
OK je préfère ça mais c’est pas logique que le comportement soit différent en UI et API pour le choix de la valeur de ce param système. On regarde et on te tient au courant