Produits Entr'ouvert » django-mellon

Un petit mot dans le README sur ce qui est attendu dans LOOKUP_BY_ATTRIBUTES et le fonctionnement associé ? (ça faciliterait en autres la relecture).

Emmanuel Cazenave a écrit :

Un petit mot dans le README sur ce qui est attendu dans LOOKUP_BY_ATTRIBUTES et le fonctionnement associé ? (ça faciliterait en autres la relecture).

Oui, oui, je voulais voir d'abord si ça buildait en python3, comme je suis en sid je n'ai pas de paquet python3-lasso malheureusement, faudrait un paquet pour buster.

Documenter aussi l'option ignore-case dans les lookups.

A titre indicatif, le _link_user est utilisé qu'un fois, et je trouve pas que ça rende le truc plus clair, je comprendrai mieux un truc comme ça :

        provisionning = False
        if not user:
            if not utils.get_setting(idp, 'PROVISION'):
                self.logger.debug('provisionning disabled, login refused')
                return None
            provisionning = True
            user = self.create_user(User)

        saml_id, link_created = models.UserSAMLIdentifier.objects.get_or_create(
            name_id=name_id, issuer=issuer, defaults={'user': user})

        if not provisionning:
            return user

        if user != saml_id.user:
            self.logger.info('looked up user %s with name_id %s from issuer %s',
                             user, name_id, issuer)
            user.delete()
            return saml_id.user

        try:
            self.finish_create_user(idp, saml_attributes, user)
        except UserCreationError:
            user.delete()
            return None
        self.logger.info('created new user %s with name_id %s from issuer %s',
                                 user, name_id, issuer)
        return user

Emmanuel Cazenave a écrit :

A titre indicatif, le _link_user est utilisé qu'un fois, et je trouve pas que ça rende le truc plus clair, je comprendrai mieux un truc comme ça :

[...]

Hmm y a pas le code de lookup_by_attributes là, ça donnerait quoi avec ? Parce que finish_create_user faut pas le faire avec le lookup.

Au niveau de 0002, on a un real_user et un user, c'est real_user qu'on a retourner à la fin donc c'est sur lui qu'il faut jouer le finish_create_user :

    user = self.create_user(User)
    real_user = self._link_user(idp, saml_attributes, issuer, name_id, user)*
    if user != real_user:
         ....
    else:
             self.finish_create_user(idp, saml_attributes, user)    <-- c'est plutôt real_user qu'il faut jouer

    return real_user

Ou alors, plus lisible pour moi, ça serait :

    user = self.create_user(User)
    real_user = self._link_user(idp, saml_attributes, issuer, name_id, user)*
    if user != real_user:
         user.delete()
         return real_user 

    ... et on continue sur "user" ensuite, on parle plus de son jumeau real_user

    return user

Globalement, quand tout est ok (utilisateur retrouvé via nameid), je ferais plutôt des logs de niveau debug, par exemple à la place de ce logger.info :

            self.logger.info('looked up user %s with name_id %s from issuer %s',
                             user, name_id, issuer)

Oui, oui, je voulais voir d'abord si ça buildait en python3, comme je suis en sid je n'ai pas de paquet python3-lasso malheureusement, faudrait un paquet pour buster.

Pourtant https://packages.debian.org/search?keywords=python3-lasso ?

Ah ben je sais juste pas utiliser apt, un -t testing m'a sauvé, merci.

Question que je me pose : et si l'utilisateur obtenu via lookup_by_attributes est déjà référencé dans un UserSAMLIdentifier (c'est-à-dire déjà fédéré avec un autre name_id) ? Je serais dans ce cas pour ne pas le prendre en compte. C'est à dire, au lieu de juste :

users_found = User.objects.filter(**{key: value})

faire :

users_found = User.objects.filter(saml_identifiers=None, **{key: value})

En passant, authentic2-auth-fedict définit aussi son Adapter, qui passe par lookup_user, rien de bien particulier, et pas un soucis si le comportement ne change pas du tout. (ce dont je ne suis pas tout à fait sûr)

_~~

pour abstraire le queryset des utilisateurs

Plus clair si c'est appelé get_users_queryset que get_queryset, je trouve.

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

En passant, authentic2-auth-fedict définit aussi son Adapter, qui passe par lookup_user, rien de bien particulier, et pas un soucis si le comportement ne change pas du tout. (ce dont je ne suis pas tout à fait sûr)

a2-auth-fedict dépend du comportement normal avec provisionning si on ne définit pas de raccordement par attribut ça doit marcher comme avant.

Plus clair si c'est appelé get_users_queryset que get_queryset, je trouve.

Ok.

Tu renommes le "get_users_queryset" ? Et ça devrait être ok selon moi.