Skip to content
Valider 0f433bc5 rédigé par marcimat@rezo.net's avatar marcimat@rezo.net
Parcourir les fichiers

Proposition de modification du fonctionnement de api_docrestreint (qui décide...

Proposition de modification du fonctionnement de api_docrestreint (qui décide de l'affichage ou non d'un document pour un visiteur).

Le code est réécrit pour limiter l'indentation (if ... return)
Factorisation de quelques parties appelées fréquemment.

On place dans un objet toutes les infos connues du document à analyser ; 
Cet objet traverse un nouveau pipeline 'accesrestreint_pre_vue_document'; 
si le 'status' dans l'objet est renseigné après ce passage, 
il est utilisé pour ce document. 

Sinon, c'est le mécanisme précédent qui s'applique,
à savoir : si ce document n'est pas présent dans spip_documents => 404, et s'il est
présent, il faut l'autorisation de le voir, par clé d'action ou par autoriser().

Un autre pipeline est aussi créé (peut être inutile ?) nommé 'accesrestreint_repertoires_toujours_autorises'
permettant de définir des sous répertoires de IMG dont on autorise systématiquement l'accès. 

Ces deux pipelines (n'hésitez pas à trouver de meilleurs nommages) devraient permettre 
de gérer plus finement l'accès restreint aux documents qui sont hors de la médiathèque.
Actuellement ils étaient systématiquement refusés, hormis ceux du sous répertoire 'nl' (newsletter).

Cela devrait permettre de gérer des documents IMG/truc/muche.tld qui nécessitent par exemple simplement d'être identifié
pour être vus. De même, le plugin newsletter pourrait maintenant indiquer que son répertoire est ouvert, soit avec
le pipeline 'accesrestreint_pre_vue_document', soit avec 'accesrestreint_repertoires_toujours_autorises' si on le garde, 
évitant ce petit code en dur dans accès restreint.


parent a1b266cf
0% ou .
You are about to add 0 people to the discussion. Proceed with caution.
Terminez d'abord l'édition de ce message.
Veuillez vous inscrire ou vous pour commenter