J’ai surchargé le paramètre système AUTH_PROVIDERS avec ma configuration, cela fonctionne très bien. Pour cela j’ai modifié le champs sys_value (pas sys_value2) et ai remplacé le module system par un module de connexion perso pour enregistrer les changements. Jusque-là tout va bien mais je suppose que ce n’est pas la bonne approche car lors de la suppression du module de connexion pour tester sa réinstallation, la paramètre système a été totalement supprimé.
Après un vider le cache je me retrouve face à une page blanche indiquant qu’aucun auth provider déclaré et donc je suis bloqué hors de l’instance.
Je ne demande pas comment réparer cela, nous avons réussi à insérer le paramètre en sql. Par contre je me questionne sur les bonnes pratiques générales pour surcharger les paramètres systèmes avec des modules proprement sans que la suppression des modules casse l’instance.
PS : j’ai relu la doc et j’ai trouvé ceci SIMPLICITE_SYSPARAM_, préfixe à appliquer pour créer un nouveau paramètre qui vient surcharger celui de base mais cela n’a pas l’air de fonctionner. J’ai bien écris SIMPLICITE_SYSPARAM_AUTH_PROVIDERS
De manière générale pour surcharger un paramètre système il y a 3 possibilités:
utiliser le sys_value2 => attention; ça ne permet pas de packager cette surcharge dans un module, c’est donc à limiter à des surcharges locales à une instance stables dans le temps
ajouter un paramètre de disposition associé à la disposition default => ça permet de packager la surcharge dans un module de son choix
utiliser une surcharge par variable d’environnement SIMPLICITE_SYSPARAM_<nom du paramètre système> (ex: SIMPLICITE_SYSPARAM_MAIL_SERVICE pour la surcharge de la configuration du serveur de mail externe) => c’est une bonne approche pour les paramètres locaux à une instance, tout particulièrement ceux contenant des données sensibles (URLs, username/password, tokens, clés d’API, etc.)
J’ajoute la possibilité de variabiliser des éléments d’un param système configuré en mode 1) ou 2) par des variables d’environnement dédiées, ex:
C’est selon moi la meilleure approche pour gérer de la variabilité locale
Sur un SIM les variables d’environnement doivent être valorisées dans le fichier .env à la racine du compte de l’instance, ex:
sim sh moninstance
vi .env
Avec une syntaxe du type:
MAVAR1=mavaleur1
MAVAR2="ma valeur 2"
IMPORTANT la prise en compte des variables d’environnement ne se fait pas “à chaud” car c’est de niveau JVM = il est donc nécessaire de relancer l’instance : sim stop puis sim start
PS: Pour réparer votre instance le plus simple est de le faire en base, sim sh mon instance puis sim db et passer la commande SQL suivante
update m_system set sys_value = '[{ "name": "simplicite", "type": "internal" }]', sys_value2 = null where sys_code = 'AUTH_PROVIDERS`;
commit;
Cette méthode ne fonctionne pas sur mon instance. J’ai essayé avec un cas plus simple. SIMPLICITE_SYSPARAM_VERSION mais le changement n’est pas pris en compte.
Application version devrait montrer 6.6.6 au lieu de 1.0.0
Même résultat sur un déploiement à base d’image Docker
Commencez par mettre à jour votre instance car la révision obsolète 6.3.7 que vous utilisez et qui date d’il y a presque 3 mois est en retard de 4 révisions (et de ~230 commit) vs la révision actuelle 6.3.11. Nous ne pouvons pas assurer de support correctement si vous ne vous maintenez pas à jour régulièrement (c’est l’un des bénéfices d’une infra SIM - ou Docker - de faciliter/automatiser les updates au fil de l’eau)
