Mark Thomas wrote:
Remy Maucherat wrote:
The input filter is added to the processor during the processing of the
final request in the FORM authentication sequence and the data in it is
consumed during the processing of this request. There is no need for
this filter, or the data in it, to persist across multiple requests.
Data is persisted between requests (of course it has to be so FORM auth
can take place) but this is done in the session and therefore it does
not matter if the processor that handles the original request is
different from the one that handles the FORM auth request or the final
redirect to the original URL.
At the moment I do see what is so badly broken about this that justifies
a -1.
If this still goes to the session, then the -1 is not justified. The
code is not done in a way that is very intuitive to me, so that's the
only issue then, and it's not relevant.
I still have trouble with the concept of saving any POST data, which
tends to be far bigger than parameters (and retrospectively, I have
trouble allowing this many parameters). This would kill clustered
Tomcats setups. Could the default be a very small value (like 64KB or
something) ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
