23 Mar
2009
23 Mar
'09
8:15 a.m.
Denis Gervalle wrote:
On 19 mars 09, at 22:55, Denis Gervalle wrote:
Well, for me the annoying use case was when FF crashes. Another very
valid use case is when changing IPs (roaming around a campus on
wireless) and the wiki is configured to include the IP in the validation
cookie. This way cookies don't just disappear, they become invalid.
The FF crashing is the one that requires the srid parameter. If I had
several tabs opened, after restarting they all get to the login screen,
so I can't save the submitted data in the session globally, because
there are several requests that need to be stored.
Anyway, is this filter causing any problems to your code? It did cause
problems to the REST framework, so it is possible that it might cause
other problems as well.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
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 ? 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.