22 Mar
2009
22 Mar
'09
1:01 p.m.
On 19 mars 09, at 22:55, Denis Gervalle wrote:
On 19 mars 09, at 17:43, Sergiu Dumitriu wrote:
Well, I should have sleep more last week ! My patch is absolutely not
working since it would have only worked as a filter, something that
xwiki authentication is not. Therefore I better understand your
approach, but why do you need a srid ?
Anyway, what I said above is still valid, from my point, there no real
life situation that could loose the cookies saved in the browser
session, except if you initially refuse them or delete them
voluntarily. Since login without accepting cookies is not really
working (and should be better handle by the way, current no warning),
I do not understand how you could unfortunately loose your
authentication ? The only advantage I see from your implementation is
the ability to POST a form request without being authenticated, and
login in the meantime to have it saved, is there such cases ?
Denis
The use case is:
- I log in
- I spend a lot of time writing a document
- I hit save
- Unfortunately, my authentication expired
- I am redirected to the login page, as I don't have the right to
save
the document as a guest
- I login
- I just lost my hard work
SavedRequestRestorer saves the posted data in the session object, so
that after authentication it can be safely retrieved and used.
Is it causing problems on your side?
No really. I have made further testing, and I had seen only one case
where the request is not properly restored:
- when your server session expire (JSESSIONID lost or invalid) and
you also loose your username and password session cookies (or
permanent cookies if you check j_remerberme).
This seems too me really unusual, and that is why I wondered about
the addition of this filter. What I would have done, probably more
in the spirit of the current (ugly?) code, is to use the already
saved request, the one saved by the Authenticator derived either
from BasicAuthenticator or FormAuthenticator, and put it back during
request wrapping.