[Cubicweb] Contexte de sécurité

Sylvain Thénault sylvain.thenault at logilab.fr
Tue Feb 17 10:11:52 CET 2015


On 16 février 19:56, Christophe de Vienne wrote:
> Salut Sylvain,

Salut Christophe,
 
> J'ai poussé ce matin un cset qui aborde le problème de façon
> radicalement différente.

pas eu le temps de regarder mais je tâche d'y jeter un oeil asap.
 
> L'idée est simplement d'injecter systématiquement les variables du
> contexte de sécurité dans les args de cnx.execute.
> 
> Le résultat est que les RQLExpressions, qu'elles soient exécutées
> directement par _check ou injectées dans les requêtes en lecture par
> rqlrewrite, peuvent faire référence à ces variables.
> 
> J'ai mis un garde-fou en interdisant que les variables du contexte
> (toutes préfixées par cnx_ dans les requêtes rql) ne soit surchargeable
> par l'appel à execute().

ok, à première vue c'est intéressant. Ça peut même résoudre un besoin qu'on a
ici, à savoir pouvoir écrire des requêtes dans l'ui (e.g pour bookmark ou card)
qui référence l'utilisateur connecté.
 
> Si cette solution est privilégiée (et il me semble qu'elle a de sérieux
> atouts), la grosse question qui reste en suspend est la façon dont nous
> y injecteront la liste des groupes auxquels l'utilisateur appartient (ce
> qui viendrait dans une étape ultérieure, mais il faut y penser quand même).
> 
> Je vois, pour l'heure, 2 options:
> 
> - chaque groupe devient une variable du contexte, possiblement préfixées
> par 'group:'. L'utilisateur admin aurait donc pour contexte:
> 
>   {'user': 12, 'group:managers': True,
>    consts.Authenticated: True, consts.Everyone: True}
> 
> - Une seule variable contient la liste des groupes:
> 
>   {'user': 12, 'groups': ['managers'],
>    consts.Authenticated: True, consts.Everyone: True}
>
> (note que dans les deux cas, j'ai ajouté de nouvelles notions
> 'authenticated' et 'everyone' sous forme de constantes, mais ce n'est
> pas vraiment le sujet de ce mail).
> 
> L'avantage de la première solution est que les variables ainsi définies
> seraient utilisables dans les requêtes RQL en cas de besoin (modulo
> l'injection de tous les autres groupes avec pour valeur 'False'),
> contrairement à la deuxième. Cette dernière est cependant plus simple à
> injecter dans le code qui vérifie les actuellement : elle semble donc
> moins disruptive et plus réaliste.

j'avoue que j'aurais besoin d'exemple sur comment on va utiliser ça dans la
vraie vie (incluant Authenticated et Everyone d'ailleurs, si possible). Ton idée
au final c'est aussi de remplacer l'usage des groupes dans les permissions du
schema par des rql expresssions ? Je suis pas sûr de comprendre pourquoi tu as
besoin d'aller plus loin que ce que tu as fait, car on peut toujours faire 'U
in_group G, G name "managers"' par ex.

> J'aimerais avoir ton avis sur la question, et comme j'ai eu la flemme de
> l'écrire en anglais (je suis en vacances pour la semaine), je te
> l'envoie en direct.
> 
> Si du français sur la liste n'est pas trop gênant, n'hésite pas à me
> répondre dessus, histoire d'avoir d'autres avis.

J'ai mis la liste en copie. 


-- 
Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org


More information about the Cubicweb mailing list