Currently, all the encryption is done in CryptoUtil#encrypt() method. Could this be an answer to your question?
Regards, Iwao on 09.5.14 7:10 AM Richard Hauswald said the following: > I noticed these tags... but didn't thought of a public form which > doesn't rely on a session. Whats about a param encryptedId or > sessionEncrypted in the Stripes validation annotation? > > On Wed, May 13, 2009 at 6:55 PM, Iwao AVE! <[email protected]> wrote: >> 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 ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
