Code review comment for lp:~joetalbott/uci-engine/add_v2_skeleton
Revision history for this message
| Joe Talbott (joetalbott) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
On Thu, Sep 25, 2014 at 01:20:15PM -0000, Celso Providelo wrote:
> Right, I remember that argument about 'supporting unauthenticated clients', specially CLI, because internal components will probably always be unauthenticated and that's fine from the security PoV and much lighter for the code maintenance/
>
> Regarding the CLI, it would have to be upgraded in order to support authenticated actions either if we block it via central Authorization class or drop v1 from the apache proxy. So, I don't see why we can't land an permissive Authorization class on v1 now and flip the restrictive switch (only authorized writes) when we upgrade the CLI. In both cases, old CLI writes would break when we get *safe*, right ?
If that's the case we don't need to do anything. All the tastypie
resources are read-only except those that need write access which
already have the default permissive authorization implementation.
So should we just reject this MP?