Je dois utiliser une librairie interne (code Renault) pour valider un token JWT fourni par un front public (exigence de nos équipes sécurité). Cette librairie présente deux dépendances qui semblent inexistantes dans le socle et que j’ai intégré pour l’instant comme ceci dans mon Dockerfile :
Est-ce la bonne manière de procéder ?
Est-il possible de les intégrer sous forme de librairie partagée Java ? (code serveur)
Est-il envisageable de les intégrer dans le socle ?
L’intégration de libs tierces doit toujours être vérifiée par nos soins car cela peut tirer des dépendances indirectes pas forcément compatibles avec les libs déjà embarquées dans la plateforme.
Je vais regarder ces deux là et je te dis (on parle bien d’une 5.2 ?)
edit : et si elles nous semblent pertinentes à intégrer (et que leur license le permet) dans le socle, on les ajoutera
Ensuite il y a 2 approches pour ajouter ces libs tierces:
en construisant une image custom et en y copiant les libs dans /usr/local/tomcat/webapps/ROOT/WEB-INF/lib
Ok, j’avais regardé suite à ta réponse et je n’ai vu que “Librairie Java” avec un champ qui semble prévu pour enregistrer la source (du coup j’ai eu un doute entre “fichier source au format .jar” ou “fichier source au format .java”…
Elles peuvent donc potentiellement être ajoutées à la plateforme soit spécifiquement soit au niveau socle
Elles font clairement double emploi avec d’autres libs qu’on utilise déjà pour la validation des tokens JWT et la gestion de cache - e.g. le cache des grants API - mais bon, elles sont en license Apache 2.0 et on est plus à 2 libs près
Bonjour David,
notre upgrade en 5.2 approche et je cherche à lever une petite dette concernant l’intégration des JAR Renault. Actuellement (en 5.1), ils sont intégrés via le Dockerfile (les libs jose4j et caffeine ont été intégrées dans le socle 5.2 donc je les retirerai lors de l’upgrade) :
Tout fonctionne bien hormis une alerte un peu crade au démarrage du container qui nous dit que la signature des JAR du système est altérée et que le comportement est imprévisible.
Afin de résoudre ça, j’essaye de passer en mode SharedCode ainsi :
Mais malgré mes tentatives je reste bloqué sur ce problème (via la fonction “Recompile all” de l’éditeur de code) :
2022-05-09 10:30:45,187|GLOBAL|INFO|2022-05-09 10:29:34,550|SIMPLICITE|INFO||http://8b3bda49f2f3:8080||INFO|system|com.simplicite.util.engine.DynamicClassLoader|compile||Event: Deleting source and binary directories
2022-05-09 10:29:34,913|SIMPLICITE|INFO||http://8b3bda49f2f3:8080||INFO|system|com.simplicite.util.engine.DynamicClassLoader|compile||Event: Compiling all classes from src:/usr/local/tomcat/webapps/ROOT/WEB-INF/src to bin:/usr/local/tomcat/webapps/ROOT/WEB-INF/jar
2022-05-09 10:29:35,572|SIMPLICITE|WARN||http://8b3bda49f2f3:8080||WARN|system|com.simplicite.util.engine.DynamicClassLoader|compile||Event: Unable to compile all classes
java.lang.Exception: Class compilation error (status 1)
/usr/local/tomcat/webapps/ROOT/WEB-INF/src/com/simplicite/commons/BCSIPublic_RCM/BCSIRCMPublicPortalToolbox.java:24: error: package com.renault.auth.config does not exist
import com.renault.auth.config.OIDCValidationParameters;
^
/usr/local/tomcat/webapps/ROOT/WEB-INF/src/com/simplicite/commons/BCSIPublic_RCM/BCSIRCMPublicPortalToolbox.java:25: error: package com.renault.auth.token does not exist
import com.renault.auth.token.AccessToken;
^
/usr/local/tomcat/webapps/ROOT/WEB-INF/src/com/simplicite/commons/BCSIPublic_RCM/BCSIRCMPublicPortalToolbox.java:26: error: package com.renault.auth.token does not exist
import com.renault.auth.token.TokenValidationRequest;
^
/usr/local/tomcat/webapps/ROOT/WEB-INF/src/com/simplicite/commons/BCSIPublic_RCM/BCSIRCMPublicPortalToolbox.java:27: error: package com.renault.auth.token does not exist
import com.renault.auth.token.TokenValidationService;
^
/usr/local/tomcat/webapps/ROOT/WEB-INF/src/com/simplicite/commons/BCSIPublic_RCM/BCSIRCMPublicPortalToolbox.java:28: error: package com.renault.auth.token.mapper does not exist
import com.renault.auth.token.mapper.IdentityProvider;
^
/usr/local/tomcat/webapps/ROOT/WEB-INF/src/com/simplicite/commons/BCSIPublic_RCM/BCSIRCMPublicPortalToolbox.java:29: error: package com.renault.auth.user does not exist
import com.renault.auth.user.UserProfile;
^
6 errors
at com.simplicite.util.engine.DynamicClassLoader.compile(DynamicClassLoader.java:189)
at com.simplicite.util.engine.CoreCache.compileAll(CoreCache.java:5680)
at com.simplicite.objects.System.Script.compileAll(Script.java:466)
En inspectant le contenu du container, je ne retrouve aucune autre trace de la lib en question qu’ici :
Ca devrait pourtant à priori marcher avec un shared code de type lib (= JAR)
S’agissant de l’approche par recopie des JARs dans une image custom, le message nous sert à détecter qu’il y a effectivement des choses qui ont été modifiées en cas de demande de support. Ca date d’un pb qu’on a mis des lustres à comprendre car on ne nous avait pas dit qu’un JAR de version conflictuelle avait été ajouté…
Les liens “shared code usage” ne servaient que pour le code Rhino partagé avec certains objets uniquement. Dans le cas de JAR additionnels, il ne faut rien mettre (c’est peut être ça qui bloque le chargement des JAR dans la JVM).
Ensuite dans l’onglet Classloader du Monitoring, vous pouvez voir les JAR chargés pour vérifier s’ils sont bien présents. Si oui, c’est un problème de code / compilation, sinon faudra tester de notre côté ce qui peut bloquer ces libs.
Ca cache sans doute quand même un pb. Car ni un rédéploiement Docker n’est pas sensé changer quelque chose et les relations d’usage ne devraient pas avoir d’effet (en mode Java elles sont juste ignorées).
