J’ai dans mon application une connexion LDAP et j’ai besoin si l’utilisateur est connu du LDAP mais pas de Simplicité de le renvoyer sur un compte read-only.
J’essaie d’utiliser la méthode parseAuth mais j’ai constamment cette erreur :
2020-02-18 09:49:46,281 ERROR [com.simplicite.util.engine.GrantManager] SIMPLICITE|http://520db8095779:8080||ECORED0001|system|com.simplicite.util.engine.GrantManager|loadProfileCache||Error Error during texts loading from cache java.lang.NullPointerException
Pouvez-vous me dire ce que j’ai oublié de renseigner dans mon GrantHooks? GrantHooks.java (1.9 KB)
Ce qui ne va pas c’est de rappeler le paseAuth dans le preLoadGrant c’est inutile et en lui passant g au lieu du grant système ça fera forcément n’importe quoi car g n’est pas encore chargé à ce stade.
Quand on arrive dans le preLoadGrant on est déjà passé par le parseAuth. Le g.getLogin() y renvoie donc ce que le parseAuth a positionné.
Sinon une autre remarque quand tu insère une valeur à une requête SQL il faut impérativement utiliser Tool.toSQL(...) pour éviter la vulnérabilité aux injections SQL
D’accord merci,
J’ai commenté le preLoadGrant mais je ne rentre pas dans le parseAuth lors de la connexion via le LDAP.
Vu que l’utilisateur n’est pas connu de simplicité, je pense que je suis bloqué
Et d’accord je ne connaissais pas Tool.toSQL(...), je l’utiliserai dorénavant.
Ok je vais regarder comment ça se passe dans ce cas précis (on est bien d’accord que tu utilise un provider d’identité LDAP) mais de mémoire historiquement le parseAuth avait été ajouté dans le cas d’une authent LDAP (pour parser les dn) donc c’est bizarre…
En attendant si tu passe Grant.getSystemAdmin() au lieu de g à ton appel de parseAuth ça devrait mieux marcher (parseAuth attend ce grant système en 1er argument, c’est historique).
PS: tu peux me redonner ta version/patchlevel/revison stp ?
Je dois l’appeler où le parseAuth ?
Je l’ai en methode static de mon GrantHooks c’est tout. Et je ne peux pas mettre Grant.getSystemAdmin() dans une méthode.
Pour ce qui est de la version de ton socle, il faut vraiment désormais basculer sur la branche “release” (image Docker “latest”), et sinon pour info depuis cette révision il y a eu pas moins de 36 commits or sur ces branches “(pre)release” ces commits sont essentiellement du correctif. On ne peut pas traiter correctement des demandes de support si l’instance n’est pas raisonnablement à jour.
C’est un workaround temporaire au fait que le parseAuth n’est à priori pas appelé = tu remets la ligne là où elle était dans ton preLoadGrant mais avec Grant.getSystemAdmin() au lieu de g.
J’investiguerai l’appel du parseAuth plus tard aujourd’hui ou demain
C’est bon j’ai mon parseAuth qui est bien appelé, mon userId qui a le bon row_id mais cela me renvoi sur la page d’authentification LDAP et dans les logs j’ai toujours cette erreur :
2020-02-18 09:49:46,281 ERROR [com.simplicite.util.engine.GrantManager] SIMPLICITE|http://520db8095779:8080||ECORED0001|system|com.simplicite.util.engine.GrantManager|loadProfileCache||Error Error during texts loading from cache java.lang.NullPointerException
package com.simplicite.commons.RCIB;
import org.json.*;
import java.util.*;
import com.simplicite.util.*;
import com.simplicite.util.tools.*;
/**
* Grant Hooks
*/
public class GrantHooks extends GrantHooksInterface {
public static String parseAuth(Grant g, String authString) {
long n = 0;
n = g.simpleQueryAsLong("select count(*) from m_user where usr_login = '"+ Tool.toSQL(authString) +"'" );
AppLog.info(GrantHooks.class, "---parseAuth", "getLogin " + g.getLogin() + " (authString " + authString + ") n = " + n, null);
if(n > 0)
return authString;
else
return "standard";
}
/**
* Generate password hook
*/
public static String generatePassword(Grant g)
{
return Tool.randomString(20);
}
private static final String[] DEFAULT_GROUPES = { "RCI_READONLY", "USER_PASSWORD" };
public static void preLoadGrant(Grant g) {
AppLog.info(GrantHooks.class, "preLoadGrant0", "Grant " + g.getLogin() + " (endpoint " + g.getEndpoint() + ") pre load (java) !", null);
if (g.isPublic() || g.isSystem() || g.isDesigner())
return;
SessionInfo info = g.getSessionInfo();
if (info != null) {
AppLog.info(GrantHooks.class, "preLoadGrant", info.toJSONObject().toString(2), null);
}
String userId = Grant.getUserId(parseAuth(Grant.getSystemAdmin(), g.getLogin())); // Retreive user ID (not loaded in g at this stage)
AppLog.info(GrantHooks.class, "userId = ", userId, null);
long n = g.simpleQueryAsLong("select count(*) from m_resp where rsp_login_id = " + userId); // Count user's responsibilities
AppLog.info(GrantHooks.class, "preLoadGrant3", "User ID " + userId + " has " + n + "responsibilities" + n, null);
if (n == 0) {
for (String groupe : DEFAULT_GROUPES)
Grant.addResponsibility(userId, groupe, Tool.getCurrentDate(), "", true, ModuleDB.getModuleName(Grant.getUserModuleId(Grant.getUserLogin(userId))));
}
}
}
Pour le user,
il a un login que le LDAP ne connait pas (=“standard”)
il a son statut enable.
Il a pour responsabilité un groupe qui n’a que des fonctions Read de tout mes objets.
Lorsque j’utilise la connexion interne à simplicité j’arrive à me connecter au compte.
Ça ne change rien, j’ai la même erreur.
J’ai fait un test un utilisant setLogin("standard") et j’ai quand même l’erreur du pointeur null sur le loadProfileCache
Ok il doit y avoir une subtilité car logiquement, comme je l’ai dit au début, il est trop tard pour appeler le parseAuth à ce niveau.
Celui ci devrait avoir été appelé plus en amont, de ce que je vois au debugger ça ne le fait pas dans le cas du provider standard LDAP, j’essaie de comprendre si c’est voulu ou si c’est un oubli ou une régression et je reviens vers toi.
Lorsque je redirige la connexion vers le compte read-only, cela met à jour les informations de
ce compte avec les informations de l’utilisateur remontées par le LDAP.
Est-ce que je peux empêcher cette mise à jour dans le cas d’une redirection ?