[pLog-svn] r7015 - plog/branches/lifetype-1.2/js/ui

[Mark Wu]

Hi Jon & Reto:

Great job, It looks nice.

For all actions exist in system include plugin actions, I think a new method
"getActionMap" could be add to Controller class, it could help CSRF plugin
to get all actions through AdminController::getActionMap() easier:

Class Controller {
...
    function getActionMap()
    {
          global $_plogController_actionMap;
          return( array_keys($_plogController_actionMap) );
    }
...
}

Since Lifetype's action map is a global array, of course this method could
be add to CsrfUrls DAO only.

Another problem is how to identify the admin action should be protected or
not, .... Jon'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't want to protect by default.

So, the CsrfUrls dao could change to:

Class CsrfUrls {
...
    $unprotected = array( 'adc', 'def' );
    function getProtectedOps($op="") {
        $protected = array_diff( AdminController::getActionMap(),
$unprotected );
        .....
    }
...
}

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( 'ghi' ) for plugin developers.

Then, plugin developers can decide the action should be protected or not.

It just my two cents.

Mark

2010/8/2 Jon Daley <plogworld at jon.limedaley.com>

> On Mon, 2 Aug 2010, Reto Hugi wrote:
>
>> I was thinking about those Blog communities that Mark was working on
>> some time ago, with lot's of content "creators". But fair enough, it's
>> only the admin side.
>>
>        Yes, I occasionally hear about large communities, but I just haven't
> worked on any of their code.
>
>  Please have a look at the /class/data/nonce.class.php (not the
>>>> randomizer - yours is better)
>>>>
>>> Well, acutally I thought that the nonce creation class would have been
>>
>> nicer, than just creating the token inside the plugin code - that was my
>> point :)
>>
>        True, that is good.
>
>
>  The "insecure" 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.
>>
>        Yeah, I'm not sure how to fix the newly-added actions part.  If you
> have any ideas about that, that'd be good.  I don't want to fix the second.
>        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.
>
>
>  my aproach involved much more work but it treats csrf protection just as
>> we treat any other validation, so it's more kind of a "native" aproach.
>>
>        True, and if we could get it in the adminaction base class, then
> it'd be great.
>
>
>  True. Although the problem is, that I'm not running the latest svn code
>> - heck, I'm still on 1.2.8!
>>
>        Hmmm...  Though I'd still venture to guess that you could just
> replace the adminloginaction and add the plugin and be good to go.  If you
> don't care about dynamically adding categories on the newpost page, you can
> ignore those changes.
>
>
> --
> Jon Daley
> http://jon.limedaley.com
> ~~
> No matter where you go,
> there you are.
> -- Buckaroo Bonzai
>
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://limedaley.com/pipermail/plog-svn/attachments/20100802/06237c74/attachment.html>