Il existe de la doc en ligne concernant l'objet proxy dont tu parles ? Le 18 novembre 2011 13:23, Dsls <dsls(a)morefnu.org&gt; a écrit : > Hello, > > Gros sujet de réflexion sur les classes core de dotclear, et de leur > utilisation actuelle. > > J'ai volontairement isolé certaines méthodes des classes dcBlog et > dcCore (voir en annexe). > Pour moi, les fonctions en question ne devraient pas être > disponibles/accessibles coté public du blog. > > Il pourrait être intéressant d'avoir une instanciation différente > selon qu'on est coté > public ou coté admin du blog : coté public, on ouvre un sous-ensemble > de fonctionnalités > (des objets core et blog bridés en quelque sorte), et coté admin on > donne les objets complets. > > Cela peut être mis en oeuvre de plusieurs façons. Exemple pour dcBlog : > * Un objet dcBlog épuré implémenté coté public, dont hérite un objet > dcBlogAdmin plus complet > * Un objet dcBlog complet coté admin, dont hérite un objet > dcBlogPublic qui surcharge les fonctions interdites > * Un objet dcBlog complet coté admin, et un objet "proxy" (au sens > design pattern du terme) utilisé en guise de > dcBlog coté public, le proxy contrôlant ce qui est appelable ou pas. > > L'avantage du 3e cas est qu'on peut mettre les behaviors qu'on veut > avant et/ou après l'appel à des fonctions core et/ou blog. > > Je conçois qu'aujourd'hui c'est assez abstrait et peut paraître > inutile, dans la mesure on on n'a pas vraiment besoin > de cette protection dans la gestion actuelle du moteur de template, > mais si on réfléchit un peu plus loin avec un nouveau moteur > de templates (twig pour ne citer que lui), offrir un objet dcBlog > "protégé" dans le contexte du template permettrait une grande > simplification de l'écriture de templates, et surtout une certaine > sécurisation à ce niveau. > > A+, > Bruno > > > == Annexe == > dcBlog : > public function __construct($core, $id) > public function addCategory($cur,$parent=0) > public function addComment($cur) > public function addPost($cur) > public function categories() > public function delCategory($id) > public function delComment($id) > public function delPost($id) > public function resetCategoriesOrder() > public function setCategoryParent($id,$parent) > public function setCategoryPosition($id,$sibling,$move) > public function > setPostContent($post_id,$format,$lang,&$excerpt,&$excerpt_xhtml,&$content,&$content_xhtml) > public function updComment($id,$cur) > public function updCommentStatus($id,$status) > public function updPost($id,$cur) > public function updPostCategory($id,$cat_id) > public function updPostSelected($id,$selected) > public function updPostStatus($id,$status) > > dcCore : > public function __construct($driver, $host, $db, $user, $password, > $prefix, $persist) > public function addBlog($cur) > public function addFormater($name,$func) > public function addUser($cur) > public function checkNonce($secret) > public function countAllComments() > public function countBlogPosts($id,$type=null) > public function emptyTemplatesCache() > public function indexAllComments($start=null,$limit=null) > public function indexAllPosts($start=null,$limit=null) > public function initWikiComment() > public function initWikiPost() > public function initWikiSimpleComment() > public function setBlog($id) > public function setUserBlogPermissions($id, $blog_id, $perms, > $delete_first=true) > public function setUserDefaultBlog($id, $blog_id) > public function setUserPermissions($id,$perms) > public function setVersion($module,$version) > public function unsetBlog() > public function updBlog($id,$cur) > public function updUser($id,$cur) > public function userDefaults() > public function wikiPostLink($url,$content) > _______________________________________________ > Dev mailing list > Dev(a)list.dotclear.org > http://ml.dotclear.org/listinfo/dev >

J'ai trouvé ça : http://www.zeitoun.net/articles/proxyfier-un-objet-php/start

J'ai volontairement isolé certaines méthodes des classes dcBlog et dcCore (voir en annexe). Pour moi, les fonctions en question ne devraient pas être disponibles/accessibles coté public du blog.

> C'est intéressant dans le concept, même si effectivement, pour > l'instant on n'a pas tellement de problème de sécurité, mais c'est un > gros boulot, ça, non ? Pas forcément. Le but est d'être transparent. Mais une fois de plus, c'est prendre un petit peu d'avance sur les grosses évolution que cela permettra ensuite. On peut très bien faire quelque chose de vraiment transparent pour l'utilisateur. > Par contre, je ne suis pas sûr de tout comprendre : les fonctions que > tu as listées devraient selon toi n'être pas disponibles en façade ? > Je comprends bien par exemple qu'on n'ai pas à faire d'update sur un > billet en façade, mais quid d'addComment par exemple ? On ne doit pas > ajouter de commentaires en façade ? > > Et pour ce qui est de l'update des billets, ça n'est pas utilisé par > les billet programmés ? J'ai fait une liste à la va-vite, j'ai peut-être laissé trop de fonctions :) L'idée est d'isoler les fonctions qui seraient vraiment "dangereuses" coté public.

Est-ce qu'un mécanisme particulier pourrait être mis en place pour autoriser tout de même, après utilisation du mécanisme en question, un plugin a utiliser une de ces fonctions côté public ? (histoire d'éviter une réécriture de code)

> Est-ce qu'un mécanisme particulier pourrait être mis en place pour > autoriser tout de même, après utilisation du mécanisme en question, un > plugin a utiliser une de ces fonctions côté public ? (histoire > d'éviter une réécriture de code) Plein de pistes sont envisageables,e le but n'étant pas de restreindre les possibilités, mais de proposer des objets simples permettant d'intéragir au niveau public avec un minimum de sécurité. Pour ton cas, rien n'empêcherait d'implémenter une fonction type "sudo" , qui fournirait un objet complet pendant un temps donné seulement. Ca existe déjà dans le core, mais sur un périmètre bien plus restreint. Pour le cas pratico-pratique, si je prends un futur passage à Twig comme moteur de templates, on va rendre un objet type dcBlog visible depuis le moteur. Dans un template on pourra par exemple écrire : {% set posts = blog.getPosts({'selected': true}) %} {% for post in posts %} ... {% endfor %} L'objet blog en question ne doit pas être une instance du dcBlog actuel, qui propose trop de fonctions, dont des fonctions qu'on ne veut absolument pas voir accédées dans le template. Les templates actuels de dotclear sont tels qu'on est sûrs qu'ils ne compromettront pas le blog, et il faut conserver cette approche. D'où la réflexion sur l'utilisation d'un objet intermédiaire, plus "sécure"... Comme je le disais, c'est uniquement une réflexion : on peut très bien toujours instancier un dcBlog actuel quelque part, et proposer un autre objet forgé de toutes pièces à coté, qui lui appellera les fonction de $core->blog. -- Bruno _______________________________________________ Dev mailing list Dev(a)list.dotclear.org http://ml.dotclear.org/listinfo/dev

Le 21 novembre 2011 10:03, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Tiens ta réponse me fait penser que j'avais des soucis quand j'avais > développé la fonction de listing des behaviours côté public car je > m'étais aperçu que l'object instancié (côté public) est restreint par > rapport à celui instancié côté admin. Entre la fonction qui permettait > de retrouver la liste des behaviours n'est pas présente côté public. Tu parles de $core->getBehaviors ? Il n'y a aucune restriction sur cette classe...

{% set posts = blog.getPosts({'selected': true}) %} {% for post in posts %} ... {% endfor %}