The problem is that we need both per-session and permanent encryption key in the same webapp.
If you look at the source, you might have noticed that the encryption key is used for encrypting some hidden form elements (_sourcePage and _fp). If per-session key is used for encrypting these values, even a login form or 'Search Product' form will raise an error when the session expires before being submitted. This would not be what you expect. Regards, Iwao on 09.5.14 1:07 AM Richard Hauswald said the following: > I had a look at the source. There is a mothod providing the encryption > key. this method already looks out for the config value of the > encryption key. if its not present, it generates a random one. We > could add another config option for a provider/factroy class for the > key. A default implementation could be included in the release of > stripes. If anyone wants another way, he could implement the factory > with the logic he wants to have. IMHO this would would not break > backwards compatibiluty if its optional. All the logic for > retrieving/storing of the key can be located in the provider class. So > if someone wants to load this keys out of a database, he could also do > so. > > On Wed, May 13, 2009 at 5:33 PM, Iwao AVE! <[email protected]> wrote: >> Hi, >> >> The topic was discussed in the following thread. >> As Tim explained, some people didn't want a session to be created >> implicitly. >> >> http://thread.gmane.org/gmane.comp.java.stripes.user/7251/focus=7251 >> >> -- >> I have been thinking about the issue... >> >> If the 'encrypted' option of the @Validate annotation can take >> another value (e.g. 'session') that uses an per-session encryption >> key, most of our requirements would be satisfied. >> Those who does not want to create a session can use encrypted = >> 'true' that uses the global encryption key. >> >> This will break the backward compatibility, but could be worth >> considering for a major update. >> >> // Iwao >> >> on 09.5.13 9:41 PM Richard Hauswald said the following: >>> After a quick look at the source code I figured out that there is no >>> way to do that. I'm not sure if this is the right place to request >>> this feature but I'll give it a try :-) >>> Here is why I think I need this feature: >>> Accoring to the docs, the same passphrase is used to encrypt/decrypt >>> values. So a user A will share the same key with user B(with different >>> htpp sessions). If user A gets an encrypted value(eg by sniffing) from >>> user B, eg a database id, he can send it to stripes and stripes will >>> decrypt it. This is IMHO a security problem. >>> >>> Any thoughts are well appreciated, >>> Richard >>> >>> On Wed, May 13, 2009 at 12:07 PM, Richard Hauswald >>> <[email protected]> wrote: >>>> Hello list, >>>> is there a way to get a different encryption key for each HTTP-Session? >>>> Thanks, >>>> Richard ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
