Hi Les, I'm very interested in REST as well. I'd be happy to contribute to this effort where able.
(comments inline) On Mon, Apr 4, 2011 at 7:17 PM, Les Hazlewood <[email protected]> wrote: > ... > 1. Support authentication caching (key: AuthenticationToken, value: > AuthenticationInfo). Since REST calls usually use HTTP BASIC > authentication and assume no server state, it would be ideal if we > didn't have a roundtrip to the datastore(s) for each REST call. > Yes, but I would encourage this to be optional (truly stateless). 2. Support custom authentication 'binding'. Currently when Shiro > authenticates a subject it puts the resulting PrincipalCollection and > authentication state in the Session to ensure it is available for the > remainder of the Subject's interaction with the application during > that session. Of course, with REST being stateless, it would be ideal > to turn this off for any authentication that occurred during a REST > call. What do you think this would look like? This seems like it is the part most orthogonal to how Shiro works now. Would it be possible to do a stateless session cookie<http://www.google.com/search?q=stateless+session+cookies>approach? With at least 4k of space <http://tools.ietf.org/html/rfc2109> in a cookie, maybe the existing Shiro session could be serialized/deserialized to/from a cookie on each request? There's a non-trivial cost involved of course, but it's a cost-space tradeoff, and it would allow the existing Shiro session mechanism to port directly to RESTful applications in a truly stateless way. Other small things: * If hardcoding HTTP methods anywhere, please consider including PATCH<http://tools.ietf.org/html/rfc5789> . * Some sort of built-in Permission matching mechanism that understands HTTP methods? --Erik
