On Wed, May 14, 2014 at 4:46 AM, Sergio <[email protected]> wrote: > Can I attach the authenticator to only some of the methods of my > resources? I.e. protect only PUT, POST, and DELETE while keeping GET > public? Maybe using roles? >
You can do per-resource or even per-method authorization: Remember that authentication and authorization are separate steps, and that you can make authentication optional. You can attach an authenticator at an outer level and then in specific methods you can examine the authenticated user (if any) and its roles to determine whether to allow or forbid a method. The authenticated user can be obtained via getClientInfo().getUser(). You can even combine these approaches: Authenticator -> Authorizer -> ... -> Resource method -> per-resource/method authorization This might be useful, for example, if you have a common level of authorization for a group of resources, but you have specific additional authorization requirements on certain resources. > If not, I'm thinking about splitting my services in two families of > resources /apps/ which will implement authentication and /info which will > be public. Do you think it is a good solution? > It depends on whether your resources naturally decompose into mutable and read-only resources. If they do, that's probably preferable. In my work I confine resource-specific authorization to a few places where it is much more natural to say something like "You must have the ADMIN role to PUT this resource, but anyone can GET it" than to break things up into separate resources. Most of the time, though, I try to keep read-only resources under separate paths in my routing structure. --tim ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3078329
