Implémentation du parseAuth

[david (David AZOULAY)]

Demande de support reçue par mail:

Peux-tu nous indiquer où doit-on placer le parseAuth ?

parseAuth est un platform hook => ça se met dans une classe “shared code” dont le nom doit être ou commencer par PlatformHooks, ex:

package com.simplicite.commons.MyModule;

import com.simplicite.util.AppLog;
import com.simplicite.util.Grant;
import com.simplicite.util.SessionInfo;

public class PlatformHooks extends com.simplicite.util.engine.PlatformHooksInterface {
	@Override
	public String parseAuth(Grant sys, SessionInfo info) {
		try {
			String login = info.getLogin();
			// Do something with login
			return login;
		} catch (Exception e) {
			AppLog.error(e, sys);
			return super.parseAuth(sys, info);
		}
	}
}

[david (David AZOULAY)]

PS:

La documentation des platform hooks a été précisée/enrichie avec cet exemple basique : Platform Hooks | Simplicité Documentation

A noter qu’il y a aussi un exemple plus poussé dans la documentation relative au connecteur OAuth2/OpenIDConnect : OAuth2 | Simplicité Documentation

[JJB (BOYE)]

J’ai réussi à override parseauth et faire un return ““ lorsque l’utilisateur n’est pas connu. Cependant le comportement générique semble être de créer un utilisateur même dans ce cas. J’ai copié ce bout de code de la doc

if (Tool.isEmpty(uid)) {
  AppLog.info("OAuth2 error: No active user for " + auth, sys);
  return “”; // ZZZ must return empty string, not null, to tell the auth is rejected
}

je vois bien apparaitre le oauth2 error dans les logs mais l’utilisateur est tout de même créé, ce n’est pas un comportement que nous souhaitons.

[JJB (BOYE)]

L’idéal sera qu’un utilisateur inconnu ne créer pas de compte mais tombe sur une page disant veuillez contacter telle adresse mail.

[david (David AZOULAY)]

Le parseAuth permet normalement de rejeter l’authentification mais ça ne fait peut être pas bon ménage avec d’autres configurations

Puis-je avoir votre AUTH_PROVIDERS afin de pouvoir tester dans les même conditions ?

Un utilisateur rejeté revient (logiquement) sur les pages d’authent.

En général c’est là que nos clients mettent les instructions pour savoir qui contacter pour se faire créer un compte, etc.

ex:

Ces contenus additionnels pour pages d’authentification correspondent aux ressources HTML LOGON_*ADDON:

Dans l’exemple ci-dessus il s’agit de la ressource HTML LOGON_PROVIDERS_ADDON:

Vous pouvez y mettre du contenu HTML libre, par exemple des liens <a href="mailto:..>` pour contact par mail

[JJB (BOYE)]

Bien pris pour savoir où afficher la consigne.
Je ne peux pas partager le auth_provider qui est interne à l’entreprise.
Par contre en faisant des tests, bien que je me déconnecte, je peux changer de profil pour passer en Designer même si je ne suis pas logué avec un compte existant. J’ai bien fait alt c c pourtant

[david (David AZOULAY)]

Pour le AUTH_PROVIDERS il suffit de masquer les URLs et les client ID/secret et il n’y aura plus rien de confidentiel.

NB: Normalement ces éléments confidentiels sont sensés être paramétrés sous forme de substitutions de variables d’environnement [ENV:...]
ex:

[
    {
        "name": "simplicite",
        "type": "internal",
        "visible": false
    },
    {
        "name": "keycloak",
        "type": "oauth2",
        "visible": true,
        "label": "Sign in with Keycloak",
        "image": "signin-with-keycloak.svg",
        "sync": true,
        "client_id": "[ENV:KEYCLOAK_CLIENT_ID]",
        "client_secret": "[ENV:KEYCLOAK_CLIENT_SECRET]",
        "base_url": "https://[ENV:KEYCLOAK_SERVER]/auth/realms/[ENV:KEYCLOAK_REALM]",
        "authorize_url": "protocol/openid-connect/auth",
        "token_url": "protocol/openid-connect/token",
        "userinfo_url": "protocol/openid-connect/userinfo",
        "logout_url": "protocol/openid-connect/logout",
        "userinfo_mappings": {
            "login": "email"
        }
    }
]

si vous les avez mis “en dur”, c’est une très mauvaise pratique

[david (David AZOULAY)]

PS: il est aussi possible de m’envoyer des choses en message privé sur ce forum, je serai le seul à les voir (mais masquez quand même les infos confidentielles)

[JJB (BOYE)]

J’ai ceci dans Overridden value :

[
  {
    "name": "monprovider",
    "type": "oauth2",
    "label": "S'identifier avec monprovider ",
    "sync": true,
    "visible": true,
    "default_scopes": "openid",
    "userinfo_mappings": { "login": "preferred_username" },
    "client_id": "\[ENV:MY\_ monprovider \_CLIENT_ID\]",
    "client_secret": "\[ENV:MY\_ monprovider \_CLIENT_SECRET\]",
    "authorize_url": "https://\[ENV:MY\_ monprovider \_URL\]/\*\*\*/auth",
    "token_url": "https://\[ENV:MY\_ monprovider \_URL\]/\*\*\*/token",
    "userinfo_url": "https://\[ENV:MY\_ monprovider \_URL\]/\*\*\*/userinfo",
    "logout_url": "https://\[ENV:MY\_ monprovider \_URL\]/\*\*\*/logout"
  },
  { "name": "simplicite", "type": "internal" , "visible": false}
\]

et cela dans Value :

[
{ "name": "simplicite", "type": "internal" }
]

[david (David AZOULAY)]

@JJB

"sync": true,

Il n’est pas impossible que la synchro et le parseAuth ne fassent pas bon ménage, dans un contexte où les users sont pré-créés la synchro n’a pas de raison d’être activée

Pouvez vous mettre "sync": false (ou ne pas le mettre du tout la valeur par défaut étant false) et retester

Merci de préciser la version exacte x.y.z de Simplicité que vous utilisez

[JJB (BOYE)]

Super, c’est bon pour moi, vous pouvez clôturer le sujet. Pour info je suis en 6.2.20

[david (David AZOULAY)]

OK tant mieux, on va regarder si on peut rendre les choses plus malignes mais j’en doute

La 6.2 est désormais en fin de vie, il va falloir passer en 6.3, normalement il n’y a pas d’impacts mais je vous laisse vérifier dans la release note si vous êtes concernés par les “breaking changes”, ça ne devrait pas être le cas car ça concerne des choses très atypiques mais on ne sait jamais…