Hi Jon &amp; Reto:<br><br>Great job, It looks nice.<br><br>For all actions exist in system include plugin actions, I think a new method &quot;getActionMap&quot; could be add to Controller class, it could help CSRF plugin to get all actions through AdminController::getActionMap() easier:<br>
<br>Class Controller {<br>...<br>    function getActionMap() <br>    {<br>          global $_plogController_actionMap;<br>          return( array_keys(<code><span style="color: rgb(0, 0, 0);"><span style="color: rgb(0, 119, 0);"></span><span style="color: rgb(0, 0, 187);"></span><span style="color: rgb(0, 119, 0);"></span></span></code>$_plogController_actionMap) );<br>
    }<br>...<br>}<br><br>Since Lifetype&#39;s action map is a global array, of course this method could be add to CsrfUrls DAO only.<br><br>Another problem is how to identify the admin action should be protected or not, .... Jon&#39;s current method is white list, it records all the actions need to protect by CSRF. Maybe, you can change it to black list, just record those ops that CSRF plugin don&#39;t want to protect by default.<br>
<br>So, the CsrfUrls dao could change to:<br><br>Class CsrfUrls {<br>...<br>    $unprotected = array( &#39;adc&#39;, &#39;def&#39; );<br>    function getProtectedOps($op=&quot;&quot;) {<br>        $protected = array_diff( AdminController::getActionMap(), $unprotected );<br>
        .....<br>    }<br>...<br>}<br><br>For further advanced CSRF protection control, maye a global variable $_plog_unprotected_actions can be added to CsrfUrls, so it can easier for CSRF plugin to provide a new method like CsrfUrls::registerUnprotectedAction( &#39;ghi&#39; ) for plugin developers. <br>
<br>Then, plugin developers can decide the action should be protected or not.<br><br>It just my two cents.<br><br>Mark<br><br><div class="gmail_quote">2010/8/2 Jon Daley <span dir="ltr">&lt;<a href="mailto:plogworld@jon.limedaley.com">plogworld@jon.limedaley.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Mon, 2 Aug 2010, Reto Hugi wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I was thinking about those Blog communities that Mark was working on<br>
some time ago, with lot&#39;s of content &quot;creators&quot;. But fair enough, it&#39;s<br>
only the admin side.<br>
</blockquote></div>
        Yes, I occasionally hear about large communities, but I just haven&#39;t worked on any of their code.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Please have a look at the /class/data/nonce.class.php (not the<br>
randomizer - yours is better)<br>
</blockquote></blockquote></div>
Well, acutally I thought that the nonce creation class would have been<div class="im"><br>
nicer, than just creating the token inside the plugin code - that was my<br>
point :)<br>
</div></blockquote>
        True, that is good.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The &quot;insecure&quot; part on the implementation is the $protected array, which may miss newly added actions and the fact that the token is fixed for a session.<br>
</blockquote></div>
        Yeah, I&#39;m not sure how to fix the newly-added actions part.  If you have any ideas about that, that&#39;d be good.  I don&#39;t want to fix the second.<br>
        I was thinking about it tonight, and wondering what it would be like to add the nonce on the javascript/client side, so then the template parsing would not be server-side, and so the load would be lower, and it would also fix the plugin issue, at least partly - in that the links could have the nonce added.  The values would still need to be validated on the other side.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
my aproach involved much more work but it treats csrf protection just as we treat any other validation, so it&#39;s more kind of a &quot;native&quot; aproach.<br>
</blockquote></div>
        True, and if we could get it in the adminaction base class, then it&#39;d be great.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
True. Although the problem is, that I&#39;m not running the latest svn code<br>
- heck, I&#39;m still on 1.2.8!<br>
</blockquote></div>
        Hmmm...  Though I&#39;d still venture to guess that you could just replace the adminloginaction and add the plugin and be good to go.  If you don&#39;t care about dynamically adding categories on the newpost page, you can ignore those changes.<div class="im">
<br>
<br>
-- <br>
Jon Daley<br>
<a href="http://jon.limedaley.com" target="_blank">http://jon.limedaley.com</a><br>
~~<br></div>
No matter where you go,<br>
there you are.<br>
-- Buckaroo Bonzai<div><div></div><div class="h5"><br>
_______________________________________________<br>
pLog-svn mailing list<br>
<a href="mailto:pLog-svn@devel.lifetype.net" target="_blank">pLog-svn@devel.lifetype.net</a><br>
<a href="http://limedaley.com/mailman/listinfo/plog-svn" target="_blank">http://limedaley.com/mailman/listinfo/plog-svn</a><br>
</div></div></blockquote></div><br>