[jira] Reopened: (MYFACES-164) Server-side state should be held

["Mathias Broekelmann (JIRA)" <my...@incubator.apache.org>]

     [ http://issues.apache.org/jira/browse/MYFACES-164?page=all ]
     
Mathias Broekelmann reopened MYFACES-164:
-----------------------------------------


I would support such a solution with a max cache param. This would make the server state more usable.

We should also make the state wrapped in a SoftReference or something like that to avoid memory problems. I´m currently not sure how to achieve that we start with the oldest state to remove if the memory shortens ...

Just a hint: the amount of states to hold doesn´t depend on the jsp file count. It depends on the number of clicks the user makes during a session and can flood your memory.

> Server-side state should be held
> --------------------------------
>
>          Key: MYFACES-164
>          URL: http://issues.apache.org/jira/browse/MYFACES-164
>      Project: MyFaces
>         Type: Improvement
>     Versions: 1.0.9m9
>  Environment: WindowsXP SP2;J2SE1.4.2_07;Tomcat4.1.31
>     Reporter: yamo
>     Priority: Minor

>
> "When I navigate back to a form that has previously been submitted, using the browser back button, I need to click the submit button twice in order for the form to actually resubmit".
> In the mailing list (myfaces-user at 15 Nov 2004), Manfred said "This problem does not exist for client-side state saving".
> To be sure, it seems work correctly, but client-side state saving have security problems.
> Client-side state is non encrypted data, so users can see the state, and tamper with it.
> It is necessary to hold sever-side state like JSF-RI 1.1_01 to use MyFaces for secure application.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira