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.
Dave Newton wrote:
Personally I kinda liked my idea of a cookie interceptor that will inject
type-converted cookie values into actions; we'll probably use something like
that for our new projects.
Dave
--- On Thu, 6/26/08, Al Sutton <[EMAIL PROTECTED]> wrote:
From: Al Sutton <[EMAIL PROTECTED]>
Subject: Re: [s2] Whats the most strutsy way of doing....
To: "Struts Users Mailing List" <user@struts.apache.org>
Date: Thursday, June 26, 2008, 10:32 AM
I was thinking more along the lines of encrypting the userId
and
password hash using AES, store the value in the cookie,
then if the
cookie is available during another session decrypt, check
everything
matches, and let them back in.
That way it avoids trying to maintain sync between the user
and the server.
Al.
Lukasz Lenart wrote:
I think there isn't any solution in Struts2, so
then, implement that
with cookies and save such cookie also on the server
side in db, you
can also allow such thing for selected users, etc.
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
