Al Sutton wrote:
Dave,
I'm completely agree it's a great idea and useful thing to do, but the
problem is what to put into the cookie and how to map it to the user.
My current favourite is encrypt the properties you want to store
(using AES for speed and JCE support), then decrypt and inject when
needed. Cookies should be considered limited to 4K (due to the joys of
RFC2109 Section 6.3), so as long as the data fits joy shall be mine :).
Al.
Hi Al,
Just another variation I use where the useragent requires javascript:
authenticate the user and generate a token; the token doesn't contain
any sensitive data;
the token is saved in a cookie and included in all requests (as cookie,
header or param)
an s2 interceptor checks the token is matched to an authenticated user.
it injects relevant details to actions
(eg. a store maps tokens to users; server-side manages expiry,
concurrent logins etc)
It's not as fast as encoding login information in the cookie but it
can't be broken. I use the same method to sign XHR requests.
If the user has checked the "remember me" box the javascript gets the
token from the cookie and resumes using it. The server it knows not to
invalidate that token.
Vulnerabilities:
- The token should be unguessable to minimize forged requests;
- as javascript is inscecure, tokens can be stolen from the cookie
(eg. by an advertisement, XSS)
I wrote the above as an S2 plugin. The only problem with releasing it as
a plugin is that the "service that checks tokens" can't be
Xwork'@Inject'ed into the interceptor (rather it has to be injected via
spring or guice) due to its potential external dependencies (eg. an
EntityManager). The same plugin also allows me to apply roles to action
methods (jsr-250).
cheers,
Jeromy Evans
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
