Return-Path: 
 <cocoon-dev-return-30270-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 16245 invoked by uid 500); 8 Aug 2002 16:39:12 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 16231 invoked from network); 8 Aug 2002 16:39:12 -0000
From: "Per Kreipke" <per@onclave.com>
To: <cocoon-dev@xml.apache.org>
Subject: RE: SunRise: AuthAction.java bug?
Date: Thu, 8 Aug 2002 12:42:01 -0400
Message-ID: <FCEPLAOECPOAGINFDFCHCEHBFMAA.per@onclave.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <GMEBIBHGAOFGJCDPJANDGEEAFAAA.cziegeler@s-und-n.de>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> I looked at the code and it seems that if the handler parameter is
> misconfigured an exception should be thrown:
>
> The AuthAction calls:
>
>             if (sunRise.checkAuthentication(redirector, !initialized) ==
> false) {
>
> And in the checkAuthentication() method, the following code should
> throw an exception then:
> >>>
>         if (this.handlerName == null) this.handlerName = "";
>         if (this.applicationName == null) this.applicationName = "";
>         if (this.handlerName.equals(newHandlerName) == false
>             || this.applicationName.equals(newAppName) == false) {
>             this.handlerName = newHandlerName;
>             this.applicationName = newAppName;
>             this.handler = null;
>             this.application = null;
>
>             if (this.handlerName != null) {
>                 if ( null != this.userHandlers) {
>                     this.handler =
> (Handler)this.userHandlers.get(this.handlerName);
>                 } else {
>                     this.handler =
> (Handler)this.configuredHandlers.get(this.handlerName);
>                 }
>
>                 if (this.handler == null) {
>                     throw new ProcessingException("Handler not found: " +
> this.handlerName);
>                 }
>
> <<<<<
>
> Or is here a bug?

Yes, I think there is, ergo the subject. But I wasn't explicit in my
description, sorry.

I admit that I can't tell by looking at the code above, I find it too
complex since I don't understand exactly how SunRise works. E.g. I have no
idea how many SunRise objects are instantiated at runtime: one per request,
per pipeline, per user, per session? And consequently I don't understand why
there is a this.handler in the SunRise object since you can declare multiple
<handler>'s within the <map:action> for SunRise. Why, for example, don't you
put the handler in the request attributes the way you did the handler name?

That said, isn't there a missing else in the block of code below the one
above?

if (this.handler != null) {
 ...
}
// no else here, which means that checkAuthentication() is valid with a
misconfiged handler?

Wish I could help more.

Per

> > In 2.0.3, the default value returned from AuthAction:act() calling
> > SunRise.java:checkAuthentication() is true even if there is no handler
> > parameter defined.
> >
> > That seems wrong to me: if misconfigured with no 'handler'
> > parameter, there
> > should either be an error message or complete failure. The user
> certainly
> > shouldn't be authorized.
> >
> > Per
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org