You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cactus-dev@jakarta.apache.org by Kazuhito SUGURI <su...@lab.ntt.co.jp> on 2004/02/26 11:53:34 UTC
FormAuthentication (bug #17933) [Re: Form Authentication is not
working in Weblogic Portal 7.0 SP4,need help]
Hi,
In article <20...@lab.ntt.co.jp>,
Fri, 20 Feb 2004 11:56:29 +0900 (JST),
Kazuhito SUGURI <su...@lab.ntt.co.jp> wrote:
suguri> I modified FormAuthentication while we (Ankur and I) were solving this.
suguri> # please refer archive of cactus-users ML for detail.
suguri>
suguri> I believe the new FormAuthentication will be a solution for a issue:
suguri> http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
suguri>
suguri> The code is appending to this message.
suguri> The code is modified from the one of the source release of Cactus-1.5.
I didn't care about difference between 1.5 and 1.6dev,
so I modified little more.
The code modified from the one of cactus-1.6dev20040225 is appending.
Followings are what I did to the original cactus-1.6dev20040225:
1. Bug #17933 is fixed (I hope so)
(1) Get hostname from a HttpURLConnection instance of the first connection,
which should contains set-cookie header field in its response,
then pass the hostname to the first argument of Cookie(String, String, String)
constructor.
(2) Use WebRequest#addCookie(Cookie) instead of WebRequest#addCookie(String, String)
2. New accessors are provided
(1) setExpectedPreAuthResponse(int)/getExpectedPreAuthResponse()
Set/get the expected HTTP response code for a request
to a restricted resource without authenticated principal.
The default is HttpURLConnection.HTTP_MOVED_TEMP.
If the response code of the first connection is not what's expected,
authentication process will not be proceeded.
(2) setExpectedAuthResponse(int)/getExpectedAuthResponse()
Set/get the expected HTTP response code for an authntication request
which should be succeeded.
The default is HttpURLConnection.HTTP_MOVED_TEMP.
If the response code of the second connection is not what's expected,
the authentication is considerd as failed.
(3) setSessionCookieName(String)/getSessionCookieName()
Set/get the cookie name of the session. The default is "JSESSIONID".
Best Regards,
----
Kazuhito SUGURI
mailto:suguri.kazuhito@lab.ntt.co.jp
Re: FormAuthentication (bug #17933)
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Hi,
In article <88...@gmx.de>,
Fri, 27 Feb 2004 13:07:37 +0100,
Christopher Lenz <cm...@gmx.de> wrote:
cmlenz> Possibly stupid question: why don't we just check for any status code <
cmlenz> 400?
I think this is enough for most of Cactus users.
For your information, followings are what I thought about
the FormAuthentication.
1. I want stop the authentication sequence and inform what's (maybe)
wrong to tester when the sequence seems goes wrong.
So, I determined to check response for each authentication step
and throw Exception if the response is not something expected.
2. At the pre-auth step, the resource set by setRedirectorName(String) may be
a) xxxRedirector and is secured:
[This case is normal.]
302 (or server depending) stats code will be returned.
b) xxxRedirector, but is not secured:
[In this case, the server should be re-configured.
or the test-case should be debugged]
500 status code will be returned.
c) not xxxRedirector but is existing secured resource:
[In this case, the test-case should be debugged.]
302 (or server depending) status code will be returned.
At this point, the sequence goes wrong, however, I cannot imagine
how to know that in the program logic.
d) not xxxRedirector but an existing un-secured resource:
[In this case, the test-case should be debugged.]
2xx status code will be returned.
The existence of the set-cookie header field is server dependent.
If the cookie is find, unexpected authentication sequence
can be proceeded (but I wanted stop it if possible).
To detect this case, I didn't use logic like if (theCode < 300),
however, the program logic not work as I want for server
which returns 2xx.
e) not existing resource:
[In this case, the test-case should be debugged, also.]
4xx status code will be returned.
3. At the auth step, the status code is also server dependent.
Server may try to return resource requested in the pre-auth step
whenever the authentication is succeeded.
Hopefully, no such server is existing, however, if server try to do so,
the response may have status code of 500 for cactus tests because
no query string is passed to the xxxRedirector at that time.
Moreover, if the security_check url set by
FormAuthentication#setSecurityCheckURL(URL) is possibly wrong,
how could I judge from the status codes? I'v never find the answer.
4. After all, I found that it's too difficult for me to determin expected
response status codes.
Then, I determined that the value should be set by one who knows it.
5. Even if the status code is that of expected, however,
that is not means the authentication sequence is successfully proceedeing.
For example, 302 status code at auth step may means
"authentication faild (try again)".
So, more complex logic is required to realize what I wanted to do
at the first time.
However, I thought, such logic gives no valuable means for Cactus.
I think there are some other better ways to track the sequence
than this status code based apploach.
Regards,
----
Kazuhito SUGURI
E-mail: suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Max Kutny <mk...@umc.ua>.
On Fri, Feb 27, 2004 at 01:07:37PM +0100, Christopher Lenz wrote:
> Am 27.02.2004 um 11:56 schrieb Max Kutny:
> >On Fri, Feb 27, 2004 at 11:05:30AM +0100, Vincent Massol wrote:
> >My bad. I've just mislooked that. But I'm also sceptic about the
> >response code defaults. E.g. I wonder if there are
> >containers that _redirect_ to the login page instead of return it in
> >the
> >200 response.
>
> Tomcat 4.x redirects to the login form, and I think Tomcat 5 also does
> so by default, although I'm not sure about that.
>
> Possibly stupid question: why don't we just check for any status code <
> 400?
You're making sence. I like that idea.
-- Max
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Christopher Lenz <cm...@gmx.de>.
Am 27.02.2004 um 11:56 schrieb Max Kutny:
> On Fri, Feb 27, 2004 at 11:05:30AM +0100, Vincent Massol wrote:
>>>> Applied in CVS HEAD (I'm doing a nightly build now)! I've made some
>>>> minor changes but mostly cosmetic (I've made the new getters private
>> as
>>>> I couldn't see why they would be useful for users).
>>>
>>> No, they are useful ;) At least my servlet container (Resin 2.1.8)
>>> returns login page as 200 response. Moreover, I believe the spec
>>> requires to do exactly the same. So we need to be accurate here in
>> case
>>> the containers interpete the spec differently.
>>
>> I've *not* made the setters private, only the getters.
>
> My bad. I've just mislooked that. But I'm also sceptic about the
> response code defaults. E.g. I wonder if there are
> containers that _redirect_ to the login page instead of return it in
> the
> 200 response.
Tomcat 4.x redirects to the login form, and I think Tomcat 5 also does
so by default, although I'm not sure about that.
Possibly stupid question: why don't we just check for any status code <
400?
Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: FormAuthentication (bug #17933)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Max Kutny [mailto:mkut@umc.ua]
> Sent: 27 February 2004 11:57
> To: Cactus Developers List
> Subject: Re: FormAuthentication (bug #17933)
>
> On Fri, Feb 27, 2004 at 11:05:30AM +0100, Vincent Massol wrote:
> > > > Applied in CVS HEAD (I'm doing a nightly build now)! I've made
some
> > > > minor changes but mostly cosmetic (I've made the new getters
private
> > as
> > > > I couldn't see why they would be useful for users).
> > >
> > > No, they are useful ;) At least my servlet container (Resin 2.1.8)
> > > returns login page as 200 response. Moreover, I believe the spec
> > > requires to do exactly the same. So we need to be accurate here in
> > case
> > > the containers interpete the spec differently.
> >
> > I've *not* made the setters private, only the getters.
>
> My bad. I've just mislooked that. But I'm also sceptic about the
> response code defaults. E.g. I wonder if there are
> containers that _redirect_ to the login page instead of return it in
the
> 200 response. If there are none it's better to make pre-auth default
to
> be HTTP_OK instead of HTTP_MOVED_TEMP so people are not required to
> explicitely set desired response code for every authenticator
instance.
Yes, I've seen your question to Kazuhito. I don't know the answer.
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Max Kutny <mk...@umc.ua>.
On Fri, Feb 27, 2004 at 11:05:30AM +0100, Vincent Massol wrote:
> > > Applied in CVS HEAD (I'm doing a nightly build now)! I've made some
> > > minor changes but mostly cosmetic (I've made the new getters private
> as
> > > I couldn't see why they would be useful for users).
> >
> > No, they are useful ;) At least my servlet container (Resin 2.1.8)
> > returns login page as 200 response. Moreover, I believe the spec
> > requires to do exactly the same. So we need to be accurate here in
> case
> > the containers interpete the spec differently.
>
> I've *not* made the setters private, only the getters.
My bad. I've just mislooked that. But I'm also sceptic about the
response code defaults. E.g. I wonder if there are
containers that _redirect_ to the login page instead of return it in the
200 response. If there are none it's better to make pre-auth default to
be HTTP_OK instead of HTTP_MOVED_TEMP so people are not required to
explicitely set desired response code for every authenticator instance.
-- Max
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Hi Max,
In article <20...@maxmobil.umc.com.ua>,
Fri, 27 Feb 2004 12:00:55 +0200,
Max Kutny <mk...@umc.ua> wrote:
mkut> No, they are useful ;) At least my servlet container (Resin 2.1.8)
mkut> returns login page as 200 response. Moreover, I believe the spec
mkut> requires to do exactly the same. So we need to be accurate here in case
mkut> the containers interpete the spec differently.
As far as I know, the detailed sequence is not determined as a spec.
The spec is only determing the security check url and parameter names
to be passed to that url. I've never seen the spec that defines
how the sequence should be proceeded. (I may be mislooking something.)
So, I believe, response code is depending on the server side implementation.
I'm not sure which one of known response codes is widely used
in existing servlet containers. But the tomcat implementation,
which returns 302, is exist as a reference. So I useed 302 as the default.
----
Kazuhito SUGURI
E-mail: suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: FormAuthentication (bug #17933)
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Max,
> -----Original Message-----
> From: Max Kutny [mailto:mkut@umc.ua]
> Sent: 27 February 2004 11:01
> To: Cactus Developers List
> Subject: Re: FormAuthentication (bug #17933)
>
> On Fri, Feb 27, 2004 at 10:24:00AM +0100, Vincent Massol wrote:
> > Applied in CVS HEAD (I'm doing a nightly build now)! I've made some
> > minor changes but mostly cosmetic (I've made the new getters private
as
> > I couldn't see why they would be useful for users).
>
> No, they are useful ;) At least my servlet container (Resin 2.1.8)
> returns login page as 200 response. Moreover, I believe the spec
> requires to do exactly the same. So we need to be accurate here in
case
> the containers interpete the spec differently.
I've *not* made the setters private, only the getters. The usage is the
following:
[...]
formAuthentication.setExpected(Pre)AuthResponse(myvalue);
[...]
why would you want to get back myvalue whereas you're the one who has
set it. Thus you already know its value... :-)
Thanks
-Vincent
>
>
> -- Max
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Max Kutny <mk...@umc.ua>.
On Fri, Feb 27, 2004 at 10:24:00AM +0100, Vincent Massol wrote:
> Applied in CVS HEAD (I'm doing a nightly build now)! I've made some
> minor changes but mostly cosmetic (I've made the new getters private as
> I couldn't see why they would be useful for users).
No, they are useful ;) At least my servlet container (Resin 2.1.8)
returns login page as 200 response. Moreover, I believe the spec
requires to do exactly the same. So we need to be accurate here in case
the containers interpete the spec differently.
-- Max
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: FormAuthentication (bug #17933)
Posted by Vincent Massol <vm...@pivolis.com>.
Ok. Makes sense. Thanks
-Vincent
> -----Original Message-----
> From: Kazuhito SUGURI [mailto:suguri.kazuhito@lab.ntt.co.jp]
> Sent: 27 February 2004 18:07
> To: cactus-dev@jakarta.apache.org
> Subject: Re: FormAuthentication (bug #17933)
>
> Thank you Vincent.
>
> In article <01...@vma>,
> Fri, 27 Feb 2004 10:24:00 +0100,
> "Vincent Massol" <vm...@pivolis.com> wrote:
> vmassol> Note: For my own understanding, could you tell me briefly why
it
> is
> vmassol> sometimes required to call setExpected(Pre)AuthResponse to
set an
> vmassol> expected response different than 302? I thought it was
standard?
>
> Yes, I think it is the defact standard.
> However, the implementation of the authentication sequence
> can be changed due to application level constraints.
>
> For example, some borwser implemented for STBs does not follow
> redirect response like 302.
> IF an application needs such browser (STB) and still requires
> the form authentication, the mechanism may be changed to something
like:
> C->S: request to the restricted resource of the server
> S: store the request information in the session scope
> S->C: return a login-form page with the response code 200
> C->S: send credentials
> S->C: return the resource requested at first,
> if the authentication succeeded
>
> As I understand, the form authentication mechanism can be customized
> to perform such kinds of sequence.
> This is why I added the accessors to the FormAuthentication.
>
> Regards,
> ----
> Kazuhito SUGURI
> E-mail: suguri.kazuhito@lab.ntt.co.jp
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Thank you Vincent.
In article <01...@vma>,
Fri, 27 Feb 2004 10:24:00 +0100,
"Vincent Massol" <vm...@pivolis.com> wrote:
vmassol> Note: For my own understanding, could you tell me briefly why it is
vmassol> sometimes required to call setExpected(Pre)AuthResponse to set an
vmassol> expected response different than 302? I thought it was standard?
Yes, I think it is the defact standard.
However, the implementation of the authentication sequence
can be changed due to application level constraints.
For example, some borwser implemented for STBs does not follow
redirect response like 302.
IF an application needs such browser (STB) and still requires
the form authentication, the mechanism may be changed to something like:
C->S: request to the restricted resource of the server
S: store the request information in the session scope
S->C: return a login-form page with the response code 200
C->S: send credentials
S->C: return the resource requested at first,
if the authentication succeeded
As I understand, the form authentication mechanism can be customized
to perform such kinds of sequence.
This is why I added the accessors to the FormAuthentication.
Regards,
----
Kazuhito SUGURI
E-mail: suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: [PATCH] expectedPreAuthResponse check logic
Posted by Max Kutny <mk...@umc.ua>.
On Mon, Mar 01, 2004 at 08:34:42PM +0900, Kazuhito SUGURI wrote:
> Hi,
>
> suguri> I would like to implement the logic, as Chris suggested,
> suguri> for pre-auth response stauts check.
>
> The patch against CVS HEAD (obtained from CVS View page) is appending.
It's always better to tell the exact version of the sources. Because
your patch failed on the last snapshost.
So I applied it two the previous one.
> Max, is this work for you?
It's working great.
Thanks.
-- Max
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: [PATCH] expectedPreAuthResponse check logic
Posted by Vincent Massol <vm...@pivolis.com>.
Thanks Kazuhito,
Applied!
Thanks a lot
-Vincent
> -----Original Message-----
> From: Kazuhito SUGURI [mailto:suguri.kazuhito@lab.ntt.co.jp]
> Sent: 01 March 2004 12:35
> To: cactus-dev@jakarta.apache.org
> Subject: [PATCH] expectedPreAuthResponse check logic
>
> Hi,
>
> In article <20...@lab.ntt.co.jp>,
> Mon, 01 Mar 2004 12:02:49 +0900 (JST),
> Kazuhito SUGURI <su...@lab.ntt.co.jp> wrote:
> suguri> I would like to implement the logic, as Chris suggested,
> suguri> for pre-auth response stauts check.
>
> The patch against CVS HEAD (obtained from CVS View page) is appending.
>
> I dropped the expectedPreAuthResponse attribute and its accessor.
> Check logic of pre-auth and auth responses are now implemented
> as corresponding protected methods,
> checkPreAuthResponse(HttpURLConnection)
> and checkAuthResponse(HttpURLConnection), for whom need to customize
the
> logic.
>
> Max, is this work for you?
>
> Regards,
> ----
> Kazuhito SUGURI
> mailto:suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
[PATCH] expectedPreAuthResponse check logic
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Hi,
In article <20...@lab.ntt.co.jp>,
Mon, 01 Mar 2004 12:02:49 +0900 (JST),
Kazuhito SUGURI <su...@lab.ntt.co.jp> wrote:
suguri> I would like to implement the logic, as Chris suggested,
suguri> for pre-auth response stauts check.
The patch against CVS HEAD (obtained from CVS View page) is appending.
I dropped the expectedPreAuthResponse attribute and its accessor.
Check logic of pre-auth and auth responses are now implemented
as corresponding protected methods, checkPreAuthResponse(HttpURLConnection)
and checkAuthResponse(HttpURLConnection), for whom need to customize the logic.
Max, is this work for you?
Regards,
----
Kazuhito SUGURI
mailto:suguri.kazuhito@lab.ntt.co.jp
Re: expectedPreAuthResponse check logic
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Hi Max,
Thank you for the comment and suggestion.
Your message gave me better understanding of the spec.
I'll post the patch soon.
Regards,
----
Kazuhito SUGURI
mailto:suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: expectedPreAuthResponse check logic [Re: FormAuthentication (bug #17933)]
Posted by Max Kutny <mk...@umc.ua>.
On Mon, Mar 01, 2004 at 12:02:49PM +0900, Kazuhito SUGURI wrote:
> Hi Max,
>
> In article <20...@maxmobil.umc.com.ua>,
> Fri, 27 Feb 2004 11:33:33 +0200,
> Max Kutny <mk...@umc.ua> wrote:
> mkut> Kazuhito, could you make the default expectedPreAuthResponse to be
> mkut> HTTP_OK instad of HTTP_MOVED_TEMP?
>
> In article <88...@gmx.de>,
> Fri, 27 Feb 2004 13:07:37 +0100,
> Christopher Lenz <cm...@gmx.de> wrote:
> cmlenz> Possibly stupid question: why don't we just check for any status code <
> cmlenz> 400?
>
> I would like to implement the logic, as Chris suggested,
> for pre-auth response stauts check.
Thanks a lot for accepting that. Actually, spec says that in the
pre-auth stage "the login form ... is sent to the client". But the Tomcat
developers decided to treat it as "the client is redirected to the login
form". I'd disagree on such treatment although it's arguably. So we
could check against either 200 or 302 in pre-auth case.
> What do you think about expectedAuthResponse?
> I'm not sure how Resin works.
For post-auth response it's not so trivial. There are two cases: success
authentication and failed authentication.
Success.
For this case the spec clearly states that the "client is redirected
to the resource". So the success authentication & authorization should be
checked against 302 code.
Failure.
For the failed authentication the 2.4 spec says:
"If the authentication fails, the error page is returned using either a
forward or a redirect, and the status code of the response is set to 200".
We have to options here:
1) the container implements internal forward so the response of failure is
200 and it could be easily distinguished from success authentication
(in which case the response is 302)
2) the container implements redirect as in success authentication case.
In this case the only chance to to check the failure is to analyse
resulting page. This complicates things a lot and I think it not even
worth to implement it.
What's interesting is that 2.3 spec says that in case of failure the
response should be set to 403. Why did the choose to change it is beyond
me.
Finalizing the said above the success authentication could be checked
against 302 (as it's done right now). And resin 2.x implements exactly
this behavior. So there is no need to change anything.
Thanks.
-- Max
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
expectedPreAuthResponse check logic [Re: FormAuthentication (bug
#17933)]
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Hi Max,
In article <20...@maxmobil.umc.com.ua>,
Fri, 27 Feb 2004 11:33:33 +0200,
Max Kutny <mk...@umc.ua> wrote:
mkut> Kazuhito, could you make the default expectedPreAuthResponse to be
mkut> HTTP_OK instad of HTTP_MOVED_TEMP?
In article <88...@gmx.de>,
Fri, 27 Feb 2004 13:07:37 +0100,
Christopher Lenz <cm...@gmx.de> wrote:
cmlenz> Possibly stupid question: why don't we just check for any status code <
cmlenz> 400?
I would like to implement the logic, as Chris suggested,
for pre-auth response stauts check.
What do you think about expectedAuthResponse?
I'm not sure how Resin works.
Regards,
----
Kazuhito SUGURI
mailto:suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Max Kutny <mk...@umc.ua>.
On Fri, Feb 27, 2004 at 01:16:11PM +0900, Kazuhito SUGURI wrote:
>
> So, I applied changes against the source distributed as
> jakarta-cactus-src-1.6dev20040225.
> I hope the code FormAuthentication.java is same...
>
> Appendings are:
> - the patch against the FormAuthentication.java
Kazuhito, could you make the default expectedPreAuthResponse to be
HTTP_OK instad of HTTP_MOVED_TEMP? As I understand the servlet spec
"login form ... is sent to the client" as opposed to the "client is
redirected to the login form". So the login form is sent back using the
ordinary 200 response.
-- Max
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: FormAuthentication (bug #17933)
Posted by Vincent Massol <vm...@pivolis.com>.
Applied in CVS HEAD (I'm doing a nightly build now)! I've made some
minor changes but mostly cosmetic (I've made the new getters private as
I couldn't see why they would be useful for users).
Thanks so much Kazuhito!
Note: For my own understanding, could you tell me briefly why it is
sometimes required to call setExpected(Pre)AuthResponse to set an
expected response different than 302? I thought it was standard?
Thanks
-Vincent
> -----Original Message-----
> From: Kazuhito SUGURI [mailto:suguri.kazuhito@lab.ntt.co.jp]
> Sent: 27 February 2004 05:16
> To: cactus-dev@jakarta.apache.org
> Subject: Re: FormAuthentication (bug #17933)
>
> Hi Vincent,
>
> First, I must apologize for my post at 26 Feb 2004 19:53:34 +0900.
> I should read the participating page before I do.
>
> In article <04...@vma>,
> Thu, 26 Feb 2004 14:41:52 +0100,
> "Vincent Massol" <vm...@pivolis.com> wrote:
> vmassol> I was trying to apply your patch but it's quite difficult. Do
you
> think
> vmassol> you could improve it in the following manner:
> vmassol>
> vmassol> 1/ send a cvs diff against CVS HEAD (unified diff)
> vmassol> 2/ apply Cactus coding conventions as defined in
> vmassol>
> http://jakarta.apache.org/cactus/participating/coding_conventions.html
> [snip]
> vmassol> 3/ provide a diff for
> vmassol> jakarta-cactus/documentation/docs/xdocs/changes.xml to
include
> your
> vmassol> changes.
>
> I tried to do so, however, I cannot connect to the CVS server at this
> moment.
> My network administrator is closing the route.
>
> So, I applied changes against the source distributed as
> jakarta-cactus-src-1.6dev20040225.
> I hope the code FormAuthentication.java is same...
>
> Appendings are:
> - the patch against the FormAuthentication.java
> - the full source code of the new FormAuthentication.java
> - action elements to be inserted in
documentation/docs/xdocs/changes.xml.
>
> vmassol> If 2/ is not right then the build fails as it's part of the
> automated
> vmassol> checks. The best way is for you to run "ant dist" in
> vmassol> jakarta-cactus/framework to see if your changes do not fail
the
> build.
> vmassol> Then what is really nice is to run the full release (ant
release)
> to
> vmassol> verify that tests still pass, etc.
>
> I confirmed "ant dist" in framework successfully finishes
> with checkstyle-3.3.
>
>
> Best Regards,
> ----
> Kazuhito SUGURI
> mailto:suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
Re: FormAuthentication (bug #17933)
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Hi Vincent,
First, I must apologize for my post at 26 Feb 2004 19:53:34 +0900.
I should read the participating page before I do.
In article <04...@vma>,
Thu, 26 Feb 2004 14:41:52 +0100,
"Vincent Massol" <vm...@pivolis.com> wrote:
vmassol> I was trying to apply your patch but it's quite difficult. Do you think
vmassol> you could improve it in the following manner:
vmassol>
vmassol> 1/ send a cvs diff against CVS HEAD (unified diff)
vmassol> 2/ apply Cactus coding conventions as defined in
vmassol> http://jakarta.apache.org/cactus/participating/coding_conventions.html
[snip]
vmassol> 3/ provide a diff for
vmassol> jakarta-cactus/documentation/docs/xdocs/changes.xml to include your
vmassol> changes.
I tried to do so, however, I cannot connect to the CVS server at this moment.
My network administrator is closing the route.
So, I applied changes against the source distributed as
jakarta-cactus-src-1.6dev20040225.
I hope the code FormAuthentication.java is same...
Appendings are:
- the patch against the FormAuthentication.java
- the full source code of the new FormAuthentication.java
- action elements to be inserted in documentation/docs/xdocs/changes.xml.
vmassol> If 2/ is not right then the build fails as it's part of the automated
vmassol> checks. The best way is for you to run "ant dist" in
vmassol> jakarta-cactus/framework to see if your changes do not fail the build.
vmassol> Then what is really nice is to run the full release (ant release) to
vmassol> verify that tests still pass, etc.
I confirmed "ant dist" in framework successfully finishes
with checkstyle-3.3.
Best Regards,
----
Kazuhito SUGURI
mailto:suguri.kazuhito@lab.ntt.co.jp
Re: FormAuthentication (bug #17933)
Posted by Kazuhito SUGURI <su...@lab.ntt.co.jp>.
Hi Vincent,
In article <04...@vma>,
Thu, 26 Feb 2004 14:41:52 +0100,
"Vincent Massol" <vm...@pivolis.com> wrote:
vmassol> I was trying to apply your patch but it's quite difficult. Do you think
vmassol> you could improve it in the following manner:
Yes. I'll do so.
Thanks your for the advice.
Regards,
----
Kazuhito SUGURI
E-mail: suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
RE: FormAuthentication (bug #17933) [Re: Form Authentication is not working in Weblogic Portal 7.0 SP4,need help]
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Kazuhito,
I was trying to apply your patch but it's quite difficult. Do you think
you could improve it in the following manner:
1/ send a cvs diff against CVS HEAD (unified diff)
2/ apply Cactus coding conventions as defined in
http://jakarta.apache.org/cactus/participating/coding_conventions.html
If 2/ is not right then the build fails as it's part of the automated
checks. The best way is for you to run "ant dist" in
jakarta-cactus/framework to see if your changes do not fail the build.
Then what is really nice is to run the full release (ant release) to
verify that tests still pass, etc.
3/ provide a diff for
jakarta-cactus/documentation/docs/xdocs/changes.xml to include your
changes.
Thanks!
-Vincent
> -----Original Message-----
> From: Kazuhito SUGURI [mailto:suguri.kazuhito@lab.ntt.co.jp]
> Sent: 26 February 2004 11:54
> To: cactus-dev@jakarta.apache.org
> Subject: FormAuthentication (bug #17933) [Re: Form Authentication is
not
> working in Weblogic Portal 7.0 SP4,need help]
>
> Hi,
>
> In article <20...@lab.ntt.co.jp>,
> Fri, 20 Feb 2004 11:56:29 +0900 (JST),
> Kazuhito SUGURI <su...@lab.ntt.co.jp> wrote:
> suguri> I modified FormAuthentication while we (Ankur and I) were
solving
> this.
> suguri> # please refer archive of cactus-users ML for detail.
> suguri>
> suguri> I believe the new FormAuthentication will be a solution for a
> issue:
> suguri> http://issues.apache.org/bugzilla/show_bug.cgi?id=17933
> suguri>
> suguri> The code is appending to this message.
> suguri> The code is modified from the one of the source release of
Cactus-
> 1.5.
>
> I didn't care about difference between 1.5 and 1.6dev,
> so I modified little more.
>
> The code modified from the one of cactus-1.6dev20040225 is appending.
>
>
> Followings are what I did to the original cactus-1.6dev20040225:
> 1. Bug #17933 is fixed (I hope so)
> (1) Get hostname from a HttpURLConnection instance of the first
> connection,
> which should contains set-cookie header field in its response,
> then pass the hostname to the first argument of Cookie(String,
String,
> String)
> constructor.
> (2) Use WebRequest#addCookie(Cookie) instead of
> WebRequest#addCookie(String, String)
>
> 2. New accessors are provided
> (1) setExpectedPreAuthResponse(int)/getExpectedPreAuthResponse()
> Set/get the expected HTTP response code for a request
> to a restricted resource without authenticated principal.
> The default is HttpURLConnection.HTTP_MOVED_TEMP.
>
> If the response code of the first connection is not what's
expected,
> authentication process will not be proceeded.
>
> (2) setExpectedAuthResponse(int)/getExpectedAuthResponse()
> Set/get the expected HTTP response code for an authntication
request
> which should be succeeded.
> The default is HttpURLConnection.HTTP_MOVED_TEMP.
>
> If the response code of the second connection is not what's
> expected,
> the authentication is considerd as failed.
>
> (3) setSessionCookieName(String)/getSessionCookieName()
> Set/get the cookie name of the session. The default is
"JSESSIONID".
>
>
> Best Regards,
> ----
> Kazuhito SUGURI
> mailto:suguri.kazuhito@lab.ntt.co.jp
---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org