Wikini

ActionEtDroitDUtilisation

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-18-234-51-17.compute-1.amazonaws.com

Droits d'utilisation des actions


[copié / collé et synthèse de différents méls par CharlesNepote]


Besoin fonctionnel

[...] il me semble important de gérer également des droits sur les actions, il ne suffit pas que l'admin technique accorde des droits à un admin fonctionnel sur une page d'administration contenant une action telle que "reinitialiser le mot de passe". Il faut également que l'action ne soit pas accessible à un simple utilisateur, qui pourrait, sinon, l'inclure dans une page de son choix et l'exécuter.
-- DavidDelon

Mille fois oui ! C'est exactement le problème qui se pose pour la sélection de feuille de style : passer par un fichier type switcher.php (que j'ai décrit), peut provoquer un trou de sécurité. Il faudrait donc passer par une action mais accessible seulement par certains utilisateurs.
-- CharlesNepote

En résumé

Cas d'utilisation fonctionnels
Proposition 1 de cas d'utilisation.

Ma première proposition me paraît a posteriori bien alambiquée et je pense avoir trouvé une solution beaucoup plus simple.
Proposition 2 de cas d'utilisation.
(1) dans le cas où on a effacé une action sujette à droit d'utilisation, il ne faut pas que l'utilisateur suivant puisse s'en reservir dans cette page.
D'un point de vu fonctionnel, il y a donc deux correspondances à ajouter :
(Les cas d'utilisation que je viens de décrire devraient être assez simple à réaliser. Hors le fichier edit.php, les grosses modifications concernent la création de nouveaux champs ou tables dans la base de données.)

Quelquesoit la proposition de cas d'utilisation, je pense qu'on ne fera pas l'économie, techniquement, d'analyser (parser) la page à chaque enregistrement pour y rechercher les éventuelles actions sujettes à droits d'utilisation. Cela risque de pénaliser un peu les performances au moment de l'enregistrement de la page.

Si vous acceptez la proposition 2, je veux bien essayer de la coder (avec une relecture de David ou Patrick, à moins que vous ne soyez volontaires), mais il faut encore se décider sur une solution pour stocker les correspondances de variables que j'ai indiqué plus haut. Il me semble que dans un premier temps, on peut utiliser la solution d'une nouvelle table formée d'un triplet "à la RDF" contenant :
cf. BaseDeDonneesEvolutive.

Cette solution me parait bien plus simple, ok pour sa mise en place -- DavidDelon

Solutions

J'ai commencé à réfléchir la-dessus.
Je pensais à une solution qui ne demande aucun changement par rapport au système actuel (simplement en considérant les actions comme des pages avec des ACL).
-- PatrickPaul

La solution est séduisante et n'est pas sans rappeler ma proposition de gérer les groupes utilisateurs et groupes de pages... via des pages...
Là aussi je pense qu'il faut bien en discuter. Ce besoin me paraît plus prioritaire que les groupes d'utilisateurs et groupes de pages.
-- CharlesNepote

Bien alors je me met au travail pour les droits sur les actions. -- PatrickPaul

Je pense qu'il y a deux grand types de solutions techniques pour la gestion des droits :

Dans les deux cas il faut gérer le droit d'accès aux actions en plus : il faut un moyen à l'application de vérifier que TelUtilisateur? a le droit d'utiliser TelleAction? (voir : BaseDeDonneesEvolutive).
Je pense qu'il faut bien prendre le temps de discuter cet aspect parce qu'il va impacter tout le développement futur de WikiNi.
Je pense aussi qu'il faut qu'on avance sur l'aspect du droit d'accès aux fonctions car cela nous permettra de mettre en place plus facilement l'upload, le choix de plusieurs feuilles de styles, etc.
-- CharlesNepote

Oui, cet aspect de gestion de droits sur les actions est un peu bloquant ... J'avoue que je ne vois pas trop l'interêt de chiffrer l'appel d'une action, du moment que son execution est conditionnée par la possessions des droits adéquats.
Ta proposition de table supplémentaire est séduisante, de toute façon il faudra bien passer par là. J'y réfléchis.
-- DavidDelon

J'avoue que je ne vois pas trop l'interêt de chiffrer l'appel d'une action, du moment que son execution est conditionnée par la possessions des droits adéquats.

C'est pour montrer que c'est bien la personne qui a les droits qui a créé ou modifié l'appel de l'action.
Exemple : 1. En tant qu'utilisateur CharlesNepote, je fait appel sur cette présente page à une action "feuille_de_style" que j'ai le droit d'utiliser (par exemple {{feuille_de_style style="une_adresse"}}). L'application détecte l'appel à cette action, détecte que c'est bien moi qui ai modifié la page et autorise donc l'enregistrement de cette page (ainsi donc que son affichage ultérieur). 2. Un UtilisateurBidon? n'ayant pas de droits sur l'action "feuille_de_style" vient modifier cette page : comment l'application détecte-t-elle que ce n'est pas lui qui a écrit {{feuille_de_style style="une_adresse"}} ? doit-elle alors lui interdire de publier toute information sur cette page ?
Ma solution : quand l'application détecte que j'ai (CharlesNepote) créé l'appel de fonction {{feuille_de_style style="une_adresse"}}, elle ajoute à cet appel ma "signature", cette signature intégrant un "checksum" de la chaîne {{feuille_de_style style="une_adresse"}} : si un autre utilisateur vient modifier la chaîne {{feuille_de_style style="une_adresse" passkey="e6ahe4kefzy8njdnch1zfa5fe3gzefef56ezf56qzf5487zgq453gfsgxcva"}}, l'application détectera que la valeur "passkey" ne signe pas correctement l'action.
(Je vais publier plus tard mes cas d'utilisation).
-- CharlesNepote

Ok, je comprends mieux ce que tu veux dire. -- DavidDelon

Mais je ne sais pas si c'est techniquement réalisable. -- CharlesNepote



Je suggère {{MonAction}} qui lors de la sauvegarde est remplacé par
- Si utilisateur anonyme ayant acces à MonAction?:
{{MonAction}}

- Si l'utilisateur identifié a accès à MonAction? par:
{{MonAction sign="EricDelord" hash="645879d2225dcdsssxddddxcxxx"}}
hash=md5(MonAction?.EricDelord.md5(password[EricDelord]))

- Si pas d'accès on remplace par {{MonAction error="no write access"}}

De meme {{MonAction sign="EricDelord" hash="645879d2225dcdsssxddddxcxxx"}} est sauvegardé comme:
- si hash=md5(MonAction?.EricDelord.md5(password[EricDelord]))
par {{MonAction sign="EricDelord" hash="645879d2225dcdsssxddddxcxxx"}}

- Si l'utilisateur identifié a accès à MonAction? par:
{{MonAction sign="utilisateur" hash="645879d2225dcdsssxddddxcxxx"}}
hash=md5(MonAction?.Utilisateur.md5(password[utilisateur]))

- Si pas d'accès on remplace par {{MonAction error="no write access"}}

Inconvenient:
- si l'utilisateur change de mot de passe il faut changer tous les hash....
- {{Mon Action}} peut être effacé...mais bon c'est un wiki ;)
--EricDelord


Sinon pour gérer les droits d'accès, pourquoi ne pas inclure des fonctions pour chaque module d'action:
Actuellement si j'inclus le module Action, j'ai mon buffer de sortie qui est alimenté, pourquoi ne pas créer une structure pour l'ensemble des modules qui soit une bibliotheque de fonctions, ie lorsque j'inclus le module MonAction?, j'inclue les fonctions:
MonAction_output($what){
switch $what:
case :noaccess
Erreur pas d'acces
case :body
Affichage standard
}
MonAction_hasaccess(privilege)
Cas simple
if (UserIsOwner?) {
}else{
}
Traitement via acls
include_once(acls.php); je fais ca car je trouve que acls devrait traité comme un module optionnel
return HasAccess?(...)


Ca semble bien modulaire et plus lisible non ?

Quelques idées en vrac par LordFarquaad:
Pour une gestion simple des actions (et, par extension, des handlers et de tout ce qu'on veut), je serais assez pour une gestion similaire à celle des fichiers sous Unix et Linux:
Au niveau des droits, on peut se contenter du droit de lecture, très simple à programmer (la méthode Action() n'a qu'à vérifier si la personne a le droit en lecture, et retourner un message d'erreur sinon).
Les deux autres sont plus compliquées:
Question: ces deux droits sont-ils vraiment nécessaires ?

Question: Comment gérer le propriétaire, le groupe et les droits des actions ?
Réponse: via des actions !
Extensions possibles:

Comment gérer les groupes ?
NB.: cela permet en une seule requête simple de tenter (par exemple) de lier un utilisateur à une action:
Si les groupes utilisateurs de chaque groupe sont stockés dans une chaine, il faut soit préocédéer avec des regexp dans la requête, soit procéder en deux requêtes (plus fréquent quand on ne sait pas exactement ce qu'on cherche)... pas glop je trouve...

Les données pourraient certainement être stockées en RSS-like, mais dans le cas présent j'y vois plusieurs inconvéniants:
  1. Il vaut mieux ne pas mélanger des informations de configuration (nom du site, root_page, navigation_links etc.) avec des informations de gestion et d'organisation. Il vaut mieux réunir des données du même type dans une même table (droits des actions/handlers etc., liste des liens interwiki et comme ça l'est déjà: liste des pages, liste des utilisateurs, ACLs, liens, referrers...). Sinon cela pose plusieurs problèmes:
    • difficulté de s'y retrouver dans les données: pour rechercher une information précise l'administrateur technique devra procéder par sélections conditionnelles (c. à d. avec une where_clause)
    • pour retrouver une information de configuration dont il a oublié le nom, il se retrouve dans un amas d'autres informations dont il n'a que faire...
    • on a un mélange de données de types différents dans une même table, ce qui empêche d'optimiser les champs (type, longueur, indexation etc.) en fonction du contenu.
  2. Mieux vaut réfléchir à une organisation plus spécifique à ce que l'on veut faire. Dans le cas présent, on veut, pour chaque action:
    • un proprio
    • un groupe
    • les permissions du prorprio
    • les permissions pour le groupe
    • les permissions pour les membres inscrits
    • les permissions pour tous
    • ...
  3. Ces informations se retrouvent pour chaque action, mieux vaut donc avoir un champ pour chacune d'entre elles, optimisé en fonction du type de données.
Cela présente plusieurs avantages:
Et il est toujours possible d'en récupérer le contenu et de le retravailler pour le présenter au format rss !
-- LordFarquaad (LordFarquaadASuivreEnPriorite)
(je parlerai plus tard de mes idées concernant les droits d'écriture, si je me souviens encore de mes idées -- LordFarquaad)


Opinion d'un utilisateur très peu informaticien.
Plus vous intégrez de choix, plus la combinatoire devient difficile à comprendre par l'utilisateur.
Plus la combinatoire sera informatiquement traitée dans chaque action, plus il y aura de pagaille possible. Risque renouvelé à chaque nouvelle action..
Bon, propositions d'un php-novice ;
Actuellement :
-Config.php contient des droits sur des actions : default_write...comment
-Chaque handler vérifie l'autorisation ex : $this-> HasAccess?("comment")
Généralisons :
-Config.php : chaque action contient une ligne default_action =>"...
-Chaque action vérifie si l'user HasAccess?("action")...
Pour plus de sureté la vérification de sécurité le vérifie ...

Ca reste simple pour l'utilisateur ET pour le bidouilleur qui veut créer une nouvelle action (c'est la grande force de wikini)
Bon, m'en demandez pas plus question php ! ... ;-o) bonne chance... -- FidelioEspoir
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]