On Thu, Mar 24, 2016 at 01:09:24PM +0100, Jan Pazdziora wrote:
> On Thu, Mar 24, 2016 at 11:39:17AM +1000, Fraser Tweedale wrote:
> >
> > Further to Rob's points, what about including the method being used
> > (HTTP GET/POST/PUT/PATCH)?  In a RESTful world this seems like an
> > important aspect to include.
> > 
> > How deep does this rabbit-hole go? :)
> The work, while focused primarily on web use-cases, should be usable
> outside of HTTP protocol. The rabbit hole might include questions
> about mapping FTP commands into some sensible list of methods that
> could be easily managed. In his work Lukáš seemed concerned by DENY
> rules not being supported (were removed from IPA), hence his regexp
> proposal with negative lookaheads to avoid
>       /               all users
>       /admin          admins
> where of course both URLs would match for access to /admin/edit but
> the longer one should win, thus serving as DENY.
> For FTP that has the potential of having to list looooong list of
> commands:
>       long-list-of-all-cmds-except-write-cmds         /       all users
>       long-list-of-write-commands                     /       admins
> If we could specify
>       *                                               /       all users
>       long-list-of-write-commands                     /       admins
> and the situation was not considered as introduction of DENY
> mechanism, it might be more feasible. We might still want to have
> "metacommands" like 'FTP:read', 'FTP:write' to group the underlying
> commands for easy maintenance and presentation.
> My preference would be not to do the methods at this time but have
> the data structured in such a way that it's easy to extend later.
This story:

  As an administrator, I want to allow any user to "GET /posts" and
  "GET /posts/\w+" but only users who are members of group "authors"
  to "POST /posts" or "(PUT|DELETE) /posts/\w+"

will be the very first story if we release without method support.
IMO it is too obvious and important a thing to omit from the initial


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to