Author: esj@rezo.net
Date: 2007-06-29 14:53:43 +0200 (ven, 29 jun 2007)
New Revision: 9620
Log:
Réduction des occurrences de 1comite:
- dans autoriser_voir, traitement du type Auteur;
- centralisation des requetes SQL portant sur les auteurs pouvant se connecter.
Dans spip/ecrire/action/acceder_document.php :
- if (in_array($qui['statut'], array('0minirezo', '1comite')))
+ if (autoriser('ecrire'))
Ca ça me paraît plus que douteux : on peut très bien être autorisé à
voir un document sans pour autant être autorisé à se rendre dans
l'espace privé. En d'autres termes si je modifie autoriser_ecrire,
pour contrôler l'accès à l'espace privé, je ne m'attends pas à ce que
ça ait un impact sur l'autorisation de visualisation d'un document.
Dans spip/ecrire/action/acceder_document.php :
- if (in_array($qui['statut'], array('0minirezo', '1comite')))
+ if (autoriser('ecrire'))
Ca ça me paraît plus que douteux : on peut très bien être autorisé à
voir un document sans pour autant être autorisé à se rendre dans
l'espace privé.
Mais bien sur, c'est toujours le cas !
Ce test ne fait que dire autrement ce qu'il y avait avant, savoir "qq qui a accès à écrire à acces à tous les documents". C'est une condition suffissante, mais pas nécessaire aujourd'hui comme hier.
> Ca ça me paraît plus que douteux : on peut très bien être autorisé à
> voir un document sans pour autant être autorisé à se rendre dans
> l'espace privé.
Mais bien sur, c'est toujours le cas !
Ce test ne fait que dire autrement ce qu'il y avait avant, savoir "qq
qui a accès à écrire à acces à tous les documents". C'est une
condition suffissante, mais pas nécessaire aujourd'hui comme hier.
Je suis d'accord que c'est le même résultat avec les autorisations par
défaut. Mais sémantiquement ça n'a rien à voir. Par exemple, sur
l'intranet que je viens de développer pour le Diplo et ses éditions
internationales, seuls les admins complets sont autorisés à "ecrire",
mais les autorisations standard s'appliquent pour tout le reste.
Simplement ils ne peuvent tous que passer par l'interface publique,
qui est gérée avec des crayons, du wiki etc.
sémantiquement ça n'a rien à voir. Par exemple, sur
l'intranet que je viens de développer pour le Diplo et ses éditions
internationales, seuls les admins complets sont autorisés à "ecrire"
Pour le moment, l'objectif à se fixer c'est de substituer les constantes en dur dans le code par des fonctions nommées rationnellement; cela fait, on ne sera plus géné par les fausses occurences (compatibilité, commentaire etc) pour avoir une vision d'ensemble des appels de fonctions et en déduire une bonne architecture de gestion de droits, que l'on pourra moduler.
Cela dit en ce qui concerne cette fonction particulièrement, elle s'appelle autoriser_voir_document, et j'aurais pu mettre tout simplement son code initial dans inc/autoriser, ce qui serait le plus rationnel mais alourdirait un peu ce fichier; je suppose que c'est cette raison qui t'as incité à ne pas le faire ?
> sémantiquement ça n'a rien à voir. Par exemple, sur
> l'intranet que je viens de développer pour le Diplo et ses éditions
> internationales, seuls les admins complets sont autorisés à "ecrire"
Pour le moment, l'objectif à se fixer c'est de substituer les
constantes en dur dans le code par des fonctions nommées
rationnellement;
Si ces fonctions sont appelées avec les mauvais arguments on ne s'en
sortira pas mieux
Cela dit en ce qui concerne cette fonction particulièrement, elle
s'appelle autoriser_voir_document, et j'aurais pu mettre tout
simplement son code initial dans inc/autoriser, ce qui serait le plus
rationnel mais alourdirait un peu ce fichier; je suppose que c'est
cette raison qui t'as incité à ne pas le faire ?
Non pas du tout, c'est même commenté deux lignes au-dessus
27 // TODO: ne devrait pas figurer dans ce fichier
28 if ($GLOBALS['meta']["creer_htaccess"] == 'oui'
29 AND !function_exists('autoriser_document_voir')) {
Mon idée c'était plutôt de migrer ce fichier dans le plugin acces_restreint
Si ces fonctions sont appelées avec les mauvais arguments on ne s'en
sortira pas mieux
mais si: le simple fait de compter facilement les appels de autoriser_ecrire, autoriser_voir etc donnera déjà des indications sur les choses à approfondir ou à regrouper.
Cela dit en ce qui concerne cette fonction particulièrement, elle
s'appelle autoriser_voir_document, et j'aurais pu mettre tout
simplement son code initial dans inc/autoriser, ce qui serait le plus
rationnel mais alourdirait un peu ce fichier; je suppose que c'est
cette raison qui t'as incité à ne pas le faire ?
Non pas du tout, c'est même commenté deux lignes au-dessus
27 // TODO: ne devrait pas figurer dans ce fichier
....
Mon idée c'était plutôt de migrer ce fichier dans le plugin acces_restreint
Comme quoi l'intention était imprécise. Cette migration est peut-etre souhaitable à terme, mais dans l'immédiat ça ne me parait pas souhaitable: il faut au contraire avoir un maximum d'exemples d'usage si on veut concevoir un système de droit bien général.
L'intention était précise, mais sa formulaition vague =-)
Cette migration est peut-
etre souhaitable à terme, mais dans l'immédiat ça ne me parait pas
souhaitable: il faut au contraire avoir un maximum d'exemples d'usage
si on veut concevoir un système de droit bien général.
Alors mettons autoriser_document_voir_dist() dans inc/autoriser
Alors mettons autoriser_document_voir_dist() dans inc/autoriser
En fait désolé, je me suis trompé : cette fonction n'a de sens QUE
dans le cas où le système sait protéger les documents, c'est-à-dire
quand le .htaccess est là pour contrôler. Donc sa valeur par défaut
devrait être {return true;} et la valeur dans le cadre du plugin
acces_restreint être la chose compliquée et moche qu'il y a dans la
fonction actuelle.
Alors mettons autoriser_document_voir_dist() dans inc/autoriser
En fait désolé, je me suis trompé : cette fonction n'a de sens QUE
dans le cas où le système sait protéger les documents, c'est-à-dire
quand le .htaccess est là pour contrôler.
