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! <harawata@...> 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.
> 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
>> On Wed, May 13, 2009 at 5:33 PM, Iwao AVE! <harawata@...> wrote:
>>> The topic was discussed in the following thread.
>>> As Tim explained, some people didn't want a session to be created
>>> 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,
>>>> On Wed, May 13, 2009 at 12:07 PM, Richard Hauswald
>>>> <richard.hauswald@...> wrote:
>>>>> Hello list,
>>>>> is there a way to get a different encryption key for each HTTP-Session?
> 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