[xwiki-devs] Authentication and SavedRequestRestorerFilter
Hi all and Sergiu in particular, I need a more flexible as well as new kind of authentication for my xwiki farm, I have therefore started a review of the current implementations (which is not really nice), as well as patch proposal (stackable auth and iopen)... I am currently puzzled by the introduction of the SavedRequestRestorerFilter in 10525 (1.5M2). When I apply the selenium test case provided on earlier version (1.4.1), I do not found any issue, and I there wonder what is the use case of this fix ? It seems to me useless in regards to the current state of the authentication code. I have also remove it from my test build, and I see no regression. Does anyone have a test case that shows the usefulness of this ? TIA. Denis
Denis Gervalle wrote:
Hi all and Sergiu in particular,
I need a more flexible as well as new kind of authentication for my xwiki farm, I have therefore started a review of the current implementations (which is not really nice), as well as patch proposal (stackable auth and iopen)...
I am currently puzzled by the introduction of the SavedRequestRestorerFilter in 10525 (1.5M2). When I apply the selenium test case provided on earlier version (1.4.1), I do not found any issue, and I there wonder what is the use case of this fix ? It seems to me useless in regards to the current state of the authentication code. I have also remove it from my test build, and I see no regression.
Does anyone have a test case that shows the usefulness of this ? TIA.
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? -- Sergiu Dumitriu http://purl.org/net/sergiu/
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. I join a simple patch (not finalized, neither review, that revert yours and do so, don't forget to remove the filter in web.xml as well), to be clearer. I feel that the best would be something in the middle, but currently I dislike the added srid parameter, and at least the need of that for the purposed currently announced. I completely agree that the current coupling with the org.securityfilter is really dependant on its implementation which is not good, but it was how the current code has been built on. I am thinking about an improvement, half way between what is the ultimate road (writing components) and the current implementation. I want something enough flexible ad robust to easily add both authenticator and authentication provider independently and chained. From what I have review, I am more and more convinced that I have to start over apart to avoid even more complexity in the current implementation, which undoubtedly lead to more bugs. I am just not sure I will had the time required :( Denis
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 ? Denis
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/
participants (2)
-
Denis Gervalle -
Sergiu Dumitriu