Produits Entr'ouvert » Mandaye

Il y a un problème pour moi que le pré-requis pour l'appairage soit qu'un objet User avec un champ username précis doive déjà exister et aussi avec la façon dont est utilisé User.username comme identifiant pivot.

Lors d'une demande d'appairage venant par exemple d'une cellule première visite dans combo on ne sais pas si l'utilisateur aura déjà été provisionné dans hobo, donc je verrai bien une création à ce moment là si jamais ce n'était pas le cas.

Concernant l'utilisation de username, au niveau d'une plateforme publik l'identifiant pivot est l'uuid qui est stocké tronqué dans User.username mais complètement dans l'objet de django-mellon UserSAMLIdentifier.name_id. Il faudrait pouvoir se baser là dessus (et construire un tel objet s'il n'existe pas).

Il manque l'authentification pour le web-service non ? Il faudrait voir dans quel mesure ce qui a été développé dans le ticket #8896 pourrait faire l'affaire et sinon voir comment l'adapter.

Je préférerai que mandayejs utilise le code qui est dans hobo et que celui-ci soit éventuellement modifié si c'est nécessaire pour servir à toutes nos applications. Pour l'instant celui-ci retourne un objet AnonymousPublikUser construit exprès pour authentic et autoriser les services à modifier les rôles, de plus le nameid est chercé dans le champ User.uuid qui n'existe pas dans mandaye donc là déjà je pense que le code ne marche pas.

Benjamin Dauvergne a écrit :

Je préférerai que mandayejs utilise le code qui est dans hobo et que celui-ci soit éventuellement modifié si c'est nécessaire pour servir à toutes nos applications. Pour l'instant celui-ci retourne un objet AnonymousPublikUser construit exprès pour authentic et autoriser les services à modifier les rôles, de plus le nameid est chercé dans le champ User.uuid qui n'existe pas dans mandaye donc là déjà je pense que le code ne marche pas.

Le fait d'utiliser de le code de hobo, rend mandaye dependant de hobo. Est ce intérressant d'avoir une dépendance hobo quand on veut juste déployer un mandaye hors publik

En passant, normalement on n'a pas d'utilisateur par service. Est ce que l'on ne peut pas juste se baser sur le fait d'avoir une requette signé ?

Josué Kouka a écrit :

Le fait d'utiliser de le code de hobo, rend mandaye dependant de hobo. Est ce intérressant d'avoir une dépendance hobo quand on veut juste déployer un mandaye hors publik

Ça ne posera pas de dépendance explicite sur hobo car ça se configure dans les settings, coté authentic j'avais fait comme cela pour tester:

# Test REST Authentication

from django.core.exceptions import ImproperlyConfigured

try:
    import hobo.rest_authentication
    REST_FRAMEWORK['DEFAULT_AUTHENTICATION_CLASSES'] = ('hobo.rest_authentication.PublikAuthentication',)
except ImportError:
    raise ImproperlyConfigured('Unable to install PublikAuthentication')

Ce code devrait aller dans un debian_config.py.

En passant, normalement on n'a pas d'utilisateur par service. Est ce que l'on ne peut pas juste se baser sur le fait d'avoir une requette signé ?

Non on ne va pas le faire pour l'instant on va rester sur ce qu'on a déjà qui est déjà se baser seulement sur le faire d'avoir une requête signée; on ira vers plus de sécurité plus tard.

Dans debian_config.py il faudrait laisser Session et BasicAuthentication en plus de PublikAuthentication (sinon c'est galère pour tester).

Ack.