Produits Entr'ouvert » Fargo

Paul Marillonnet a écrit :

Est-ce qu'on encore ici des cas d'usages qui sortent du support OAuth2 dans Fargo ?

Non, je ne pense pas.

Ça ne ressemble pas à ce qui est fait dans petale, il faut faire pareil, voir petale/authentication.py

Notamment hériter de BasicAuthentication.

Et je découperai un peu plus, d'abord on bouge tout dans fargo/utils.py, ensuite on remplace les vues par des vues à base de classes, ensuite on vire authenticate_client() pour une classe d'authentification basée sur BasicAuthentication, ensuite on ajoute la délégation à authentic.

Je vais relire ça ce soir.

0003: ajout de l'authentification via l'idp.

J'étais curieux sur cette API utilisée côté authentic j'ai regardé et il me semble qu'on a une exigence sur une permission particulière :

class CheckPasswordAPI(BaseRpcView):
    permission_classes = (DjangoPermission('custom_user.search_user'),)
    serializer_class = CheckPasswordSerializer

mais ici :

            response = requests.post(url, json={
                'username': client_id,
                'password': client_secret}, auth=(client_id, client_secret), verify=False)

l'appel se fait en http basic auth avec les identifiants de l'utilisateur qu'on veut checker, qui n'a sans doute pas custom_user.search_user.

(et verify=False…)

Ça a été testé en local avec un vrai authentic et autre chose qu'un compte admin ?

Frédéric Péters a écrit :

0003: ajout de l'authentification via l'idp.

J'étais curieux sur cette API utilisée côté authentic j'ai regardé et il me semble qu'on a une exigence sur une permission particulière :

[...]

mais ici :

[...]

l'appel se fait en http basic auth avec les identifiants de l'utilisateur qu'on veut checker, qui n'a sans doute pas custom_user.search_user.

(et verify=False…)

Ça a été testé en local avec un vrai authentic et autre chose qu'un compte admin ?

Le droit d'accès à l'API pour les clients OIDC est défini au niveau du model avec has_api_access.
Ensuite pour les permissions un (Fake User) OIDCUser est renvoyé avec toutes les permissions accordées (tout est dans src/authentic/authentication)

Ça a été testé en local avec un vrai authentic et autre chose qu'un compte admin ?

C'est moi qui ait dit des bêtises à Josué, il faut effectivement un compte particulier pour accéder à cette API, sur CUT/pétale j'utilise des credentials OIDC juste pour cela (sachant qu'on a une authentification pour les APIs basée dessus qui file toutes les permissions).

Donc Josué première remarque, faudrait un setting FARGO_AUTHENTIC_AUTH en plus du FARGO_AUTHENTIC_URL, idem voir petale.

En fait je suis con, ça va fonctionner ce que fait Josué, d'ailleurs on s'est fait chier pour rien sur petale.

L'API check_password, elle est appelée ici comme pourrait être appelée une API ping qui ne ferait rien, la question du check des credentials étant déjà assurée avant, c'est bien ça ?

Ici effectivement les mêmes credentials servent aux deux, mais l'API a bien un usage si je veux tester les identifiants d'un autre utilisateur qui lui n'a pas le droit d'accéder à cette API. Pour l'instant elle ne fait rien de très intéressant cette API à part dire oui ou non, mais on pourrait imaginer renvoyer un cookie de session à utiliser par une appli mobile.

Frédéric Péters a écrit :

Ça a été testé en local avec un vrai authentic et autre chose qu'un compte admin ?

Oui oui.