svn commit: r412987 - in /lenya/trunk/src: java/org/apache/lenya/cms/ac/usecases/ webapp/lenya/confi

Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
> 
> [...]
> 
>> anyways, right now i'm totally mystified by
something else. somehow 
>> the "user" attribute is reset when the
usecase moves on, but i don't 
>> know when or by what.
> 
> This happens because the usecase component is released
before the
> response is sent, and recreated when the continuation
is called.
> This is necessary to avoid that stale components
aren't released.
> 
> All usecase handler classes have to be stateless, but
the parameters
> are restored, so you have to use parameters instead of
fields.

ahh. ok, that explains many things 

but i wonder: are these parameters sent to the client? iiuc
yes.
does that mean there is no way to store persistent
information in a way 
that cannot be tampered with by injecting POST or GET
parameters, i.e. 
to keep state information on the server side?




-- 
"Open source takes the bullshit out of
software."
	- Charles Ferguson on TechnologyReview.com

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-adminuni-due.de, Telefon: 0203/379-2736

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier wrote:
>>
>> [...]
>>
>>> anyways, right now i'm totally mystified by
something else. somehow 
>>> the "user" attribute is reset when
the usecase moves on, but i don't 
>>> know when or by what.
>>
>> This happens because the usecase component is
released before the
>> response is sent, and recreated when the
continuation is called.
>> This is necessary to avoid that stale components
aren't released.
>>
>> All usecase handler classes have to be stateless,
but the parameters
>> are restored, so you have to use parameters instead
of fields.
> 
> ahh. ok, that explains many things 
> 
> but i wonder: are these parameters sent to the client?
iiuc yes.
> does that mean there is no way to store persistent
information in a way 
> that cannot be tampered with by injecting POST or GET
parameters, i.e. 
> to keep state information on the server side?

Yes, unfortunately this is true. It was the main reason why
I had
to introduce a new class ChangePasswordWithCheck.

The most straightforward way would be to convert the Usecase
Avalon
components to POJOs. This would mean that the initialization
and
disposal wouldn't be handled by the container, but it would
solve
the state information problem.

Here's a thread about this issue (no idea how to get a
thread view):

http://mail-archives.apache.org/mod_mbox
/lenya-dev/200504.mbox/%3Cd3iq49$6ef$1sea.gmane.org%3E

What do the others think?

-- Andreas

-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org