On Mon, Apr 4, 2011 at 8:04 PM, Erik Beeson <[email protected]> wrote: > 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 approach?
My apologies Erik - when I hit reply, I didn't notice the stateless session cookie link in your original email. I see now that the author of that link uses a MAC to ensure that the cookie wasn't tampered with before/during transit. This could definitely be a viable approach. (for those unaware, a MAC - Message Authentication Code - can be thought of a keyed hash. It is a hash that can only be computed with a key. This is stronger than a regular hash since it can't be computed by anyone except for key holder(s).) I do think this can be a viable approach, especially if coupled with cryptography (i.e. maybe the cookie is encrypted before computing the MAC so even it's raw state is not viewable client-side). Thanks very much for the link! I think for now though, the two points I mentioned earlier (authc caching and disabling authc binding to the session) are a lot easier problems to solve and could be done in short order. Implementing a session as a cookie is a lot harder, since you have to ensure that the cookie is updated every time session state is altered (or more elegantly, only once right before the response begins to render), and you also have to ensure that no one uses the session after a response has started rendering (since the cookie header would have already gone out on the response). As always though, patches are welcome if anyone wants to attempt this! Best, Les
