Bug in Combining Authorization Constraints

[Nam T. Nguyen]

Hi

I have two  elements in my deployment descriptor.

One has auth-constraint *, and the other does not
have any . They both have a same .

By SRV.12.8.1 Combining Constraints:


A security constraints that does not contain an authorization constraint
shall combine with authorization constraints that name or imply roles to
allow unauthenticated access.


Applying to the attached .war file, my interpretation of this is access
to /index.jsp is accepted. However, Tomcat 5.5.12 returns status code
401 (Authorization Required).

Cheers
Nam

--
Random humorous quote: Work is the greatest thing in the world, so save
some for tomorrow.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug in Combining Authorization Constraints

[Nam T. Nguyen]

Replying to my own post.

Sorry, the attachment mysteriously disappeared. Anyway, the important
part is here



Index 1
/index.jsp


*




Index 2
/index.jsp



Cheers
Nam

--
Random humorous quote: The only problem with mornings is that they
happen too early in the day.


Subject: Bug in Combining Authorization Constraints

Hi

I have two  elements in my deployment descriptor.

One has auth-constraint *, and the other does not
have any . They both have a same .

By SRV.12.8.1 Combining Constraints:


A security constraints that does not contain an authorization constraint
shall combine with authorization constraints that name or imply roles to
allow unauthenticated access.


Applying to the attached .war file, my interpretation of this is access
to /index.jsp is accepted. However, Tomcat 5.5.12 returns status code
401 (Authorization Required).

Cheers
Nam

--
Random humorous quote: Work is the greatest thing in the world, so save
some for tomorrow.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] APR or NIO ?

[Henri Gomez]

Well why so much noise about NIO/APR ?

If some want to experiment APR or NIO, why can't they do their works
on some sort of incubations projets and when stable enough give us
benchmarks results.

Benchmarks/tesings should give us information on :

stability, speed, memory usage, IO usage and of course we should have
these on many platforms. For example if the alternative implementation
is running fast as hell on Linux but has no gain on Windows or iSeries
should we consider it usefull to users ?

Also should we depend on APR on a java centric project ?

I've got no problem with APR, it's a very good piece of code, running
well even on exotic platforms like iSeries (and probably BS2000 jfc
?), but should we use a native library as the fundation of Java
products ?

Also since we're speaking about a future Tomcat redesign, shouldn't we
take care of the future JVM implementations ? Sun, IBM JVMs for now
but in the future GJC and upcoming Harmony ? If these use APR or
something similar in native land, should we use APR directly ?

I'd like to see here pragmatics informations on gains expected when
using NIO/APR/WHATEVER in real life situations which is what users and
admins expects.

Have a good day and peace on Tomcat Dev community

>2005/11/21, Costin Manolache <[EMAIL PROTECTED]>:
> I hope you are not serious... Sorry if I sounded too critical of the
> APR code - it is a great
> piece of code in many ways, I just didn't like some (probably minor) things.
>
> If you have a problem with 'refactoring' - right now it is in sandbox,
> and I can as well
> change the package name and make it a completely separate connector.
> And I'm in no hurry to
> check anything in the main branch - the sandbox is prefect for me, so
> no need to worry about this.
>
> Costin
>
> On 11/20/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> > Costin Manolache wrote:
> > > On 11/19/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> > >
> > >>Costin Manolache wrote:
> > >>
> > >>>< > 1. Yes, it's how things should be done
> > >>>< >  2. No, it can be done better
> > >>>
> > >>>My opionion is (2).
> > >>
> > >>My opinion is 1. I will not participate in the design of the upcoming
> > >>Tomcat branch, then.
> > >
> > > Well, I'm not planning any 'upcoming branch' - or 'design' for that
> > > matter, just
> > > small adjustments, in sandbox first.
> >
> > Fair enough. The minute you commit your "refactoring" to the main
> > branch, I will leave this project (besides casual bugfixing).
> >
> > Rémy
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] APR or NIO ?

[Remy Maucherat]

Costin Manolache wrote:

I hope you are not serious... Sorry if I sounded too critical of the
APR code - it is a great
piece of code in many ways, I just didn't like some (probably minor) things.


Ok, but it helped make me realize I should maintain my own tree anyway, 
since my plans are a bit opposed to your refactoring. Also, I have 
medium term requirements which most likely are going to not fit with 
what Tomcat needs :(



If you have a problem with 'refactoring' - right now it is in sandbox,
and I can as well
change the package name and make it a completely separate connector.
And I'm in no hurry to
check anything in the main branch - the sandbox is prefect for me, so
no need to worry about this.


Yes, I guess I shouldn't complain too much about code which is being 
designed in the sandbox, sorry about that :)


> I don't like 'alghoritms that behave in sublty different ways', or
> duplicating extremely complex
> classes just for 3-4 lines of code that is different. I know it is
> simpler to write and probably maintain the code ( for people who wrote
> it ), but not easier to understand for me.

Yes, I understand that, but for me the algorithm is already a bit 
complex since, although it looks similar, the process method is 
completely different. Hopefully, it has no bugs right now !


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] APR or NIO ?

[Remy Maucherat]

Henri Gomez wrote:

Well why so much noise about NIO/APR ?


Because I don't want to have to support 20 different connector 
technologies (you can call it a business requirement). So one has to be 
labelled as "experimental" or something. Similarly, the connector 
options right now are (for me) a bit too large.



If some want to experiment APR or NIO, why can't they do their works
on some sort of incubations projets and when stable enough give us
benchmarks results.

Benchmarks/tesings should give us information on :

stability, speed, memory usage, IO usage and of course we should have
these on many platforms. For example if the alternative implementation
is running fast as hell on Linux but has no gain on Windows or iSeries
should we consider it usefull to users ?

Also should we depend on APR on a java centric project ?


Apparently not ;)


I've got no problem with APR, it's a very good piece of code, running
well even on exotic platforms like iSeries (and probably BS2000 jfc
?), but should we use a native library as the fundation of Java
products ?


The code it replaces in the JVM is all native, written by the JVM 
vendor. For most users, it's written by Sun, and parts of it (java.nio 
select functionality, for example) have seen reliability issues. Fixing 
these kind of problems in this key component (at least in the case of a 
web server) requires updating the whole JVM. Besides Sun, and hopefully 
the other JVM vendors, I don't see how to actually do support on a NIO 
Tomcat.


APR OTOH is used heavily in a similar production usage on all the 
platforms that we want to support.



Also since we're speaking about a future Tomcat redesign, shouldn't we
take care of the future JVM implementations ? Sun, IBM JVMs for now
but in the future GJC and upcoming Harmony ? If these use APR or
something similar in native land, should we use APR directly ?


Unless the said JVMs get certified, I think only a few people are going 
to use them for real usage. BTW, yes, APR is still needed, as the JVM 
can only expose a small subset of the functionality through java.nio.



I'd like to see here pragmatics informations on gains expected when
using NIO/APR/WHATEVER in real life situations which is what users and
admins expects.


I can give a real life example using AJP where the current connector 
doesn't work. If you have many front end Apache servers and few Tomcat 
servers, since the AJP connections are persistent, the backend servers 
will not be able to serve requests. APR allows using a poller for 
keepalive, so this solves the problem and the thread count on backend 
servers will remain sane.



Have a good day and peace on Tomcat Dev community


Ok :)

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] APR or NIO ?

[Oleg Kalnichevski]

On Mon, Nov 21, 2005 at 11:55:08AM +0100, Remy Maucherat wrote:
> Henri Gomez wrote:
> >Well why so much noise about NIO/APR ?
> 
> Because I don't want to have to support 20 different connector 
> technologies (you can call it a business requirement). So one has to be 
> labelled as "experimental" or something. Similarly, the connector 
> options right now are (for me) a bit too large.
> 


Remy,

If you think this is a problem why do not you consider making Coyote API
more abstract and let people with specific requirements develop their
stuff as separate projects outside Tomcat proper, while you can
concentrate on developing one or two standard connectors that serve the
needs of the majority of users? Presently Coyote API is tightly coupled
with the default HTTP implementation, which makes development of third
party connectors difficult. Another problem is that some transport layer
aspects such as cookie handling are presently implemented in Catalina
and are intermingled with application layer aspects whereas they should 
be implemented by connectors and made customizable to allow for
application specific or non-standard behaviours.

If Coyote API were more abstract and less dependent on concrete classes
in the o.a.tomcat.util package it would foster a greater ecology of
smaller projects around Tomcat and would allow interested parties to
experiment with alternative connector architectures with minimal to no
involvement on the part of Tomcat committers

Cheers,

Oleg


> >If some want to experiment APR or NIO, why can't they do their works
> >on some sort of incubations projets and when stable enough give us
> >benchmarks results.
> >
> >Benchmarks/tesings should give us information on :
> >
> >stability, speed, memory usage, IO usage and of course we should have
> >these on many platforms. For example if the alternative implementation
> >is running fast as hell on Linux but has no gain on Windows or iSeries
> >should we consider it usefull to users ?
> >
> >Also should we depend on APR on a java centric project ?
> 
> Apparently not ;)
> 
> >I've got no problem with APR, it's a very good piece of code, running
> >well even on exotic platforms like iSeries (and probably BS2000 jfc
> >?), but should we use a native library as the fundation of Java
> >products ?
> 
> The code it replaces in the JVM is all native, written by the JVM 
> vendor. For most users, it's written by Sun, and parts of it (java.nio 
> select functionality, for example) have seen reliability issues. Fixing 
> these kind of problems in this key component (at least in the case of a 
> web server) requires updating the whole JVM. Besides Sun, and hopefully 
> the other JVM vendors, I don't see how to actually do support on a NIO 
> Tomcat.
> 
> APR OTOH is used heavily in a similar production usage on all the 
> platforms that we want to support.
> 
> >Also since we're speaking about a future Tomcat redesign, shouldn't we
> >take care of the future JVM implementations ? Sun, IBM JVMs for now
> >but in the future GJC and upcoming Harmony ? If these use APR or
> >something similar in native land, should we use APR directly ?
> 
> Unless the said JVMs get certified, I think only a few people are going 
> to use them for real usage. BTW, yes, APR is still needed, as the JVM 
> can only expose a small subset of the functionality through java.nio.
> 
> >I'd like to see here pragmatics informations on gains expected when
> >using NIO/APR/WHATEVER in real life situations which is what users and
> >admins expects.
> 
> I can give a real life example using AJP where the current connector 
> doesn't work. If you have many front end Apache servers and few Tomcat 
> servers, since the AJP connections are persistent, the backend servers 
> will not be able to serve requests. APR allows using a poller for 
> keepalive, so this solves the problem and the thread count on backend 
> servers will remain sane.
> 
> >Have a good day and peace on Tomcat Dev community
> 
> Ok :)
> 
> R?my
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r345898 - /tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java

[remm]

Author: remm
Date: Mon Nov 21 04:46:09 2005
New Revision: 345898

URL: http://svn.apache.org/viewcvs?rev=345898&view=rev
Log:
- Either I am completely mistaken, or the type used was wrong.

Modified:

tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java

Modified: 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java?rev=345898&r1=345897&r2=345898&view=diff
==
--- 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
 (original)
+++ 
tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11AprProcessor.java
 Mon Nov 21 04:46:09 2005
@@ -1173,8 +1173,8 @@
 InputFilter savedBody = new SavedRequestInputFilter(body);
 savedBody.setRequest(request);
 
-InternalInputBuffer internalBuffer = (InternalInputBuffer)
-request.getInputBuffer();
+InternalAprInputBuffer internalBuffer = (InternalAprInputBuffer)
+request.getInputBuffer();
 internalBuffer.addActiveFilter(savedBody);
 }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to turn the Digester off?

[anita kulshreshtha]

 Since there was no reply, I am assuming that
turning off the digester is not straightforward. Could
someone please point me to the relevant code?

Thanks
Anita

--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:

>  I am using tomcat as an embedded engine and the
> web.xml is parsed once by Geronimo. I want to avoid
> the duplicate work.
> 
> Thanks
> Anita
> 
> --- Sriram N <[EMAIL PROTECTED]> wrote:
> 
> > Hi Anita,
> > 
> > --- anita kulshreshtha <[EMAIL PROTECTED]>
> wrote:
> > 
> > > Hi all, 
> > >  Is there a way to turn off the Digester so
> > that
> > > it does not parse the web.xml at all?
> > > 
> > 
> > Digester parses web.xml and creates a hierarchy of
> > objects per web application
> > context. This is a necessary part of deploying a
> Web
> > Application in Tomcat.
> > 
> > What exactly do you wish to accomplish by turning
> > off the web.xml parsing ?
> > 
> > > Thanks In Advance
> > > Anita
> > > 
> > -- Sriram
> > 
> > 
> > 
> > __ 
> > Start your day with Yahoo! - Make it your home
> page!
> > 
> > http://www.yahoo.com/r/hs
> > 
> >
>
-
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > 
> > 
> 
> 
> 
>   
>   
> __ 
> Yahoo! Mail - PC Magazine Editors' Choice 2005 
> http://mail.yahoo.com
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 




__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] APR or NIO ?

[Costin Manolache]

On 11/21/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > I hope you are not serious... Sorry if I sounded too critical of the
> > APR code - it is a great
> > piece of code in many ways, I just didn't like some (probably minor) things.
>
> Ok, but it helped make me realize I should maintain my own tree anyway,
> since my plans are a bit opposed to your refactoring. Also, I have
> medium term requirements which most likely are going to not fit with
> what Tomcat needs :(

Well, my need is the sandbox - so I can experiment and understand the
many things
that happened in the last years.

I didn't propose any major refactoring or new requirements - I might
need 2-3 lines of code changed in the main branch for single-jar ( it
works now with the main branch as is, but it's not
perfect ). For NIO - all I want is to see for myself how it works and
what it can do. That's what the  sandbox is supposed to do.

If you want to maintain your own tree and have some new requirements -
say so, and maybe they can go in the main branch, or maybe if they are
extremely unusual ( I doubt ) in sandbox.

>
> Yes, I guess I shouldn't complain too much about code which is being
> designed in the sandbox, sorry about that :)

Again, 'designed' is a too strong word. "Toyed with" maybe.


>
>  > I don't like 'alghoritms that behave in sublty different ways', or
>  > duplicating extremely complex
>  > classes just for 3-4 lines of code that is different. I know it is
>  > simpler to write and probably maintain the code ( for people who wrote
>  > it ), but not easier to understand for me.
>
> Yes, I understand that, but for me the algorithm is already a bit
> complex since, although it looks similar, the process method is
> completely different. Hopefully, it has no bugs right now !

Everything has bugs :-)

Yes, that is my point - it looks similar, but I had problems to
understand the differences. It's not
about comments or documentation - but about the code organization,
looking at the diffs was my
only way to understand.

Again, I don't want to touch something that works - just to
understand, and maybe create a similar prototype using NIO. Or maybe a
smaller APR connector that I can play with in 'coyote
standalone' mode ( I want to keep it as small as possible ). Or maybe
try to write a small NIO provider using APR ( and put to rest this
debate about what is better ). I don't know - just want to play in the
sandbox :-)

Costin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to turn the Digester off?

[Remy Maucherat]

anita kulshreshtha wrote:

 Since there was no reply, I am assuming that
turning off the digester is not straightforward. Could
someone please point me to the relevant code?

Thanks
Anita

--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:



I am using tomcat as an embedded engine and the
web.xml is parsed once by Geronimo. I want to avoid
the duplicate work.


You mean Geronimo does the parsing of web.xml, TLDs, etc, to correctly 
setup servlets and listeners ?

I would find that surprising.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37132] - Digest authentication does not work if the username or URI contain a comma

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37132


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|ASSIGNED|NEW




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Bug in Combining Authorization Constraints

[Bill Barker]

This should be fixed in the SVN trunk, and will appear in 5.5.13.

Thanks for reporting this!

- Original Message - 
From: "Nam T. Nguyen" <[EMAIL PROTECTED]>

To: 
Sent: Monday, November 21, 2005 1:21 AM
Subject: Bug in Combining Authorization Constraints


Hi

I have two  elements in my deployment descriptor.

One has auth-constraint *, and the other does not
have any . They both have a same .

By SRV.12.8.1 Combining Constraints:


A security constraints that does not contain an authorization constraint
shall combine with authorization constraints that name or imply roles to
allow unauthenticated access.


Applying to the attached .war file, my interpretation of this is access
to /index.jsp is accepted. However, Tomcat 5.5.12 returns status code
401 (Authorization Required).

Cheers
Nam

--
Random humorous quote: Work is the greatest thing in the world, so save
some for tomorrow.








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED] 




This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r348087 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java

[billbarker]

Author: billbarker
Date: Mon Nov 21 21:06:40 2005
New Revision: 348087

URL: http://svn.apache.org/viewcvs?rev=348087&view=rev
Log:
The rule is that you authenticate if *all* security-constraints include an 
auth-constraint.  If you have a problem with this, take it up with the Servlet 
expert-group ;-).

Reported By: Nam T. Nguyen <[EMAIL PROTECTED]>


Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java?rev=348087&r1=348086&r2=348087&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java
 Mon Nov 21 21:06:40 2005
@@ -468,28 +468,33 @@
  */
 return;
 }
-   
-for(i=0; i < constraints.length; i++) {
-// Authenticate based upon the specified login configuration
-if (constraints[i].getAuthConstraint()) {
+
+// Since authenticate modifies the response on failure,
+// we have to check for allow-from-all first.
+boolean authRequired = true;
+for(i=0; i < constraints.length && authRequired; i++) {
+if(!constraints[i].getAuthConstraint()) {
+authRequired = false;
+} 
+}
+ 
+if(authRequired) {  
+if (log.isDebugEnabled()) {
+log.debug(" Calling authenticate()");
+}
+if (!authenticate(request, response, config)) {
 if (log.isDebugEnabled()) {
-log.debug(" Calling authenticate()");
+log.debug(" Failed authenticate() test");
 }
-if (!authenticate(request, response, config)) {
-if (log.isDebugEnabled()) {
-log.debug(" Failed authenticate() test");
-}
-/*
- * ASSERT: Authenticator already set the appropriate
- * HTTP status code, so we do not have to do anything
- * special
- */
-return;
-} else {
-break;
-}
-}
+/*
+ * ASSERT: Authenticator already set the appropriate
+ * HTTP status code, so we do not have to do anything
+ * special
+ */
+return;
+} 
 }
+
 if (log.isDebugEnabled()) {
 log.debug(" Calling accessControl()");
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: svn commit: r348087 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java

[Nam T. Nguyen]

This is in accordance with both Servlet and JACC specs.

JACC spec gives higher precedence to  unchecked permissions than checked
permissions.

Complaints should go to both groups :D

Cheers
Nam


--
Random humorous quote: Usually I try to take it one day at a time, but
lately several have attacked me at once...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 22, 2005 1:07 PM
To: tomcat-dev@jakarta.apache.org
Subject: svn commit: r348087 -
/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authent
icator/AuthenticatorBase.java

Author: billbarker
Date: Mon Nov 21 21:06:40 2005
New Revision: 348087

URL: http://svn.apache.org/viewcvs?rev=348087&view=rev
Log:
The rule is that you authenticate if *all* security-constraints include
an auth-constraint.  If you have a problem with this, take it up with
the Servlet expert-group ;-).

Reported By: Nam T. Nguyen <[EMAIL PROTECTED]>


Modified:
 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java

Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java
URL:
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/shar
e/org/apache/catalina/authenticator/AuthenticatorBase.java?rev=348087&r1
=348086&r2=348087&view=diff

==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java (original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java Mon Nov 21 21:06:40 2005
@@ -468,28 +468,33 @@
  */
 return;
 }
-   
-for(i=0; i < constraints.length; i++) {
-// Authenticate based upon the specified login
configuration
-if (constraints[i].getAuthConstraint()) {
+
+// Since authenticate modifies the response on failure,
+// we have to check for allow-from-all first.
+boolean authRequired = true;
+for(i=0; i < constraints.length && authRequired; i++) {
+if(!constraints[i].getAuthConstraint()) {
+authRequired = false;
+} 
+}
+ 
+if(authRequired) {  
+if (log.isDebugEnabled()) {
+log.debug(" Calling authenticate()");
+}
+if (!authenticate(request, response, config)) {
 if (log.isDebugEnabled()) {
-log.debug(" Calling authenticate()");
+log.debug(" Failed authenticate() test");
 }
-if (!authenticate(request, response, config)) {
-if (log.isDebugEnabled()) {
-log.debug(" Failed authenticate() test");
-}
-/*
- * ASSERT: Authenticator already set the
appropriate
- * HTTP status code, so we do not have to do
anything
- * special
- */
-return;
-} else {
-break;
-}
-}
+/*
+ * ASSERT: Authenticator already set the appropriate
+ * HTTP status code, so we do not have to do anything
+ * special
+ */
+return;
+} 
 }
+
 if (log.isDebugEnabled()) {
 log.debug(" Calling accessControl()");
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r348091 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/RealmBase.java

[billbarker]

Author: billbarker
Date: Mon Nov 21 21:18:05 2005
New Revision: 348091

URL: http://svn.apache.org/viewcvs?rev=348091&view=rev
Log:
Fix for a couple of (mostly silly) edge-cases in testing auth.

If any security-contraint doesn't have a auth-constraint, then we pass.
Otherwise, if any security-constraint has an , then deny 
access to everyone.
Otherwise, much as before (e.g. allow to the first constraint that allows it).


Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/RealmBase.java

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/RealmBase.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/RealmBase.java?rev=348091&r1=348090&r2=348091&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/RealmBase.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/realm/RealmBase.java
 Mon Nov 21 21:18:05 2005
@@ -724,26 +724,26 @@
 
 // Which user principal have we already authenticated?
 Principal principal = request.getPrincipal();
+boolean status = false;
+boolean denyfromall = false;
 for(int i=0; i < constraints.length; i++) {
 SecurityConstraint constraint = constraints[i];
 String roles[] = constraint.findAuthRoles();
 if (roles == null)
 roles = new String[0];
 
-if (constraint.getAllRoles())
-return (true);
+if (constraint.getAllRoles() && !denyfromall)
+status = true;
 
 if (log.isDebugEnabled())
 log.debug("  Checking roles " + principal);
 
 if (roles.length == 0) {
 if(constraint.getAuthConstraint()) {
-response.sendError
-(HttpServletResponse.SC_FORBIDDEN,
- sm.getString("realmBase.forbidden"));
 if( log.isDebugEnabled() )
 log.debug("No roles ");
-return (false); // No listed roles means no access at all
+status = false; // No listed roles means no access at all
+denyfromall = true;
 } else {
 if(log.isDebugEnabled())
 log.debug("Passing all access");
@@ -752,25 +752,24 @@
 } else if (principal == null) {
 if (log.isDebugEnabled())
 log.debug("  No user authenticated, cannot grant access");
-response.sendError
-(HttpServletResponse.SC_FORBIDDEN,
- sm.getString("realmBase.notAuthenticated"));
-return (false);
-}
-
+status = false;
+} else if(!denyfromall) {
 
-for (int j = 0; j < roles.length; j++) {
-if (hasRole(principal, roles[j]))
-return (true);
-if( log.isDebugEnabled() )
-log.debug( "No role found:  " + roles[j]);
+for (int j = 0; j < roles.length; j++) {
+if (hasRole(principal, roles[j]))
+status = true;
+if( log.isDebugEnabled() )
+log.debug( "No role found:  " + roles[j]);
+}
 }
 }
 // Return a "Forbidden" message denying access to this resource
-response.sendError
-(HttpServletResponse.SC_FORBIDDEN,
- sm.getString("realmBase.forbidden"));
-return (false);
+if(!status) {
+response.sendError
+(HttpServletResponse.SC_FORBIDDEN,
+ sm.getString("realmBase.forbidden"));
+}
+return status;
 
 }
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: svn commit: r348087 - /tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenticator/AuthenticatorBase.java

[Nam T. Nguyen]

Sorry, I'm just being dump here. My comment should be for r348091
instead of this r348087.

Shamefully yours
Nam


--
Random humorous quote: Monday is an awful way to spend 1/7th of your
life.

-Original Message-
From: Nam T. Nguyen [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 22, 2005 1:17 PM
To: Tomcat Developers List
Subject: RE: svn commit: r348087 -
/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authent
icator/AuthenticatorBase.java

This is in accordance with both Servlet and JACC specs.

JACC spec gives higher precedence to  unchecked permissions than checked
permissions.

Complaints should go to both groups :D

Cheers
Nam


--
Random humorous quote: Usually I try to take it one day at a time, but
lately several have attacked me at once...

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 22, 2005 1:07 PM
To: tomcat-dev@jakarta.apache.org
Subject: svn commit: r348087 -
/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authent
icator/AuthenticatorBase.java

Author: billbarker
Date: Mon Nov 21 21:06:40 2005
New Revision: 348087

URL: http://svn.apache.org/viewcvs?rev=348087&view=rev
Log:
The rule is that you authenticate if *all* security-constraints include
an auth-constraint.  If you have a problem with this, take it up with
the Servlet expert-group ;-).

Reported By: Nam T. Nguyen <[EMAIL PROTECTED]>


Modified:
 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java

Modified:
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java
URL:
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/shar
e/org/apache/catalina/authenticator/AuthenticatorBase.java?rev=348087&r1
=348086&r2=348087&view=diff

==
---
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java (original)
+++
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/authenti
cator/AuthenticatorBase.java Mon Nov 21 21:06:40 2005
@@ -468,28 +468,33 @@
  */
 return;
 }
-   
-for(i=0; i < constraints.length; i++) {
-// Authenticate based upon the specified login
configuration
-if (constraints[i].getAuthConstraint()) {
+
+// Since authenticate modifies the response on failure,
+// we have to check for allow-from-all first.
+boolean authRequired = true;
+for(i=0; i < constraints.length && authRequired; i++) {
+if(!constraints[i].getAuthConstraint()) {
+authRequired = false;
+} 
+}
+ 
+if(authRequired) {  
+if (log.isDebugEnabled()) {
+log.debug(" Calling authenticate()");
+}
+if (!authenticate(request, response, config)) {
 if (log.isDebugEnabled()) {
-log.debug(" Calling authenticate()");
+log.debug(" Failed authenticate() test");
 }
-if (!authenticate(request, response, config)) {
-if (log.isDebugEnabled()) {
-log.debug(" Failed authenticate() test");
-}
-/*
- * ASSERT: Authenticator already set the
appropriate
- * HTTP status code, so we do not have to do
anything
- * special
- */
-return;
-} else {
-break;
-}
-}
+/*
+ * ASSERT: Authenticator already set the appropriate
+ * HTTP status code, so we do not have to do anything
+ * special
+ */
+return;
+} 
 }
+
 if (log.isDebugEnabled()) {
 log.debug(" Calling accessControl()");
 }



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Create JNDIRealm in admin webapp is not correct.

[Terry Zhou]

Hi, gents,

Regarding this mail,
http://marc.theaimsgroup.com/?l=tomcat-user&m=113035775420898&w=2

  I have tested both tomcat admin app and MBean createJNDIRealm can't
create a realm successfully with Tomcat5.5.12. I have checked some code
and found a bug in creating an JNDIRealm. The signature of
createJNDIRealm in MBeanFactory.java is not enough, it only has one
parameter called parent, if we want to create an JNDIRealm through JMX,
we need another three parameters, they are
ConnectionURL,ConnectionName,ConnectionPassword.If we provide this
information, the JNDIRealm can be initialized correctly,so you can set
other attribute to the realm.
   Attachments are the patches for admin webapp and the MBeanFactory
modification with tc5.5.x, I have tested it, and it can work now,
  Another improvement is I add createJAASRealm in MBeanFactory for
tomcat source code didn't contain creating JAASRealm JMX API,so I add
it, it can work too.
   
  The above problem I haven't fire a bug in bugzilla, if it's necessary,
I can do it.

  Thanks.

Terry Zhou 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37588] New: - Creating JNDIRealm through JMX is not correct.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37588

   Summary: Creating JNDIRealm through JMX is not correct.
   Product: Tomcat 5
   Version: 5.5.12
  Platform: Other
OS/Version: other
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


This is the bug from
http://marc.theaimsgroup.com/?l=tomcat-dev&m=113264006531391&w=2
the user group can't contain a attachment,so I fire this bug to attach the
patch.Bellow is the bug description I pasted here.


Regarding this mail,
http://marc.theaimsgroup.com/?l=tomcat-user&m=113035775420898&w=2

  I have tested both tomcat admin app and MBean createJNDIRealm can't
create a realm successfully with Tomcat5.5.12. I have checked some code
and found a bug in creating an JNDIRealm. The signature of
createJNDIRealm in MBeanFactory.java is not enough, it only has one
parameter called parent, if we want to create an JNDIRealm through JMX,
we need another three parameters, they are
ConnectionURL,ConnectionName,ConnectionPassword.If we provide this
information, the JNDIRealm can be initialized correctly,so you can set
other attribute to the realm.
   Attachments are the patches for admin webapp and the MBeanFactory
modification with tc5.5.x, I have tested it, and it can work now,
  Another improvement is I add createJAASRealm in MBeanFactory for
tomcat source code didn't contain creating JAASRealm JMX API,so I add
it, it can work too.
   
  The above problem I haven't fire a bug in bugzilla, if it's necessary,
I can do it.

  Thanks.

Terry Zhou

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 37588] - Creating JNDIRealm through JMX is not correct.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=37588





--- Additional Comments From [EMAIL PROTECTED]  2005-11-22 07:57 ---
Created an attachment (id=17011)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17011&action=view)
Modify CreateJNDIRealm signature of  MBeanFactory and related admin webapp 

This patch also include the admin webapp patch and new improvement of
CreateJAASRealm method.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]