No, not really. I solved the problem in a very ugly way by creating my own implementation of the CryptoUtil class which is placed in the projects source folder. Now the class loader prefers this one over the original one. I'm using guice as DI framework so I bound the encryption key to a random encryption key generator and the session scope. Works for me.... until a new version of stripes is available :-(
To solve this problem permanently I can think of an optional config param defining a FactoryClass which is would be responsible for key generation/storing/reuse. Since this is optional it will not break backwards compatibility. I thought about what Iwao said: >>> 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. If the FactoryClass is smart enough this would not happen. By smart enough I mean it could look if a user is logged in and if its not the case providing a static key. Using guice this is not a problem. IMHO the whole CryptoUtil class needs refactoring since it effectively breaks multithreading of request and(!) response processing by using synchronized methods to retrieve the encryption key. This means that a request will block the rendering of a response and vice versa! I don't the the point in providing a static setter for the encryption key since changing the static field holding the encryption key after application startup would break the whole decryption support for already rendered pages. The factory method approach would also fix this issue. I would also do the coding of this feature since I really need this feature. Any thoughts are well appreciated! Regards, Richard On Sat, May 16, 2009 at 4:26 PM, Iwao AVE! <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
