19 Mar
2009
19 Mar
'09
5:25 p.m.
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
19 Mar
19 Mar
5:43 p.m.
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/
10:55 p.m.
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
22 Mar
22 Mar
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.
23 Mar
23 Mar
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.
5716
days inactive
5720
days old
4 comments
2 participants
participants (2)
-
Denis Gervalle -
Sergiu Dumitriu