Denis Gervalle wrote: > On 19 mars 09, at 22:55, Denis Gervalle wrote: > >> On 19 mars 09, at 17:43, Sergiu Dumitriu wrote: >> >>> 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. > > 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 ?
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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
