FW: Tomcat 4.0.1 / 4.0.2b2 + IIS +

[Joakim Ahlén <jo...@geosition.com>]

Hi,

A couple of months ago i posted a question regarding security
constraints with tomcat 4.0.1 (Original post attached at the bottom).
Since then, i've gotten mail from five or six people who have had the
same problem but been unable to solve it, asking me if i did. So i
thought i'd post what i do know about the problem so far.

It seems to be a bug/feature in tomcat 4.0.1 / ISAPI-filter as opposed
to other versions of the software. I haven't tested that many setups,
but i'll write a list at the end of this mail. Basic thing is, i got it
working with tomcat 4.0.2b2 + mod_jk, and tomcat 4.0.3 + mod_jk, but
never with Tomcat 4.0.1.

Tomcat 4.0.1 + IIS			Does NOT work
Tomcat 4.0.1 + Apache/mod_webapp	Does NOT work
Tomcat 4.0.1 + Apache/mod_jk		Not tested

Tomcat 4.0.2b2 + IIS			Not tested
Tomcat 4.0.2b2 + Apache/mod_webapp	Not tested
Tomcat 4.0.2b2 + Apache/mod_jk	Works!

Tomcat 4.0.3 + IIS			Not tested
Tomcat 4.0.3 + Apache/mod_webapp	Not tested
Tomcat 4.0.3 + Apache/mod_jk		Works!	

It would be very interesting to hear if any of the other setups works.
Unfortunately, I don't have the time to test them myself, but feel free
to update this list if you test the various setups.

> -----Original Message-----
> From: Joakim Ahlén [mailto:joakima@geosition.com] 
> Sent: Thursday, March 07, 2002 9:27 AM
> To: 'Wojtek Piaseczny'
> Subject: RE: Tomcat 4.0.1 / 4.0.2b2 + IIS + <security-constraint>
> 
> 
> Hi,
> 
> Actually, i never solved the problem... But as a matter of 
> fact, i got it working with another setup just the other day 
> by installing Tomcat 4.0.3 and using mod_jk + apache instead, 
> this time on a linux machine (but i guess that doesn't matter). 
> 
> With a little luck, the bug was fixed with the upgrade to 
> tomcat 4.0.3... This might be the case since i previously had 
> no luck with for example 4.0.1 + apache + mod_webapp. I have 
> not tested this setup with 4.0.3 yet, but if you give it a 
> try, please let me know how it went. :) It might be 
> interesting to know if this is fixed with tomcat 4.0.3 + 
> anything, or if it's just my installation with mod_jk it works.
> 
> //Jocke
> 
> -----Original Message-----
> From: Wojtek Piaseczny [mailto:wojtek_p@hotmail.com] 
> Sent: Friday, March 01, 2002 7:34 PM
> To: joakima@geosition.com
> Subject: Tomcat 4.0.1 / 4.0.2b2 + IIS + <security-constraint>
> 
> 
> Hi,
> 
> I have run into the same problem trying to use Tomcat 
> authentication through IIS. I came across your posting in a 
> news group and noticed it is over one month old, so I thought 
> that maybe you were able to resolve this problem on your own. 
> If you were, I would greatly appreciate any hints as to how 
> you did it. 
> 
> Thanks,
> 
> Wojtek

------------------------------------------------------------------------
Original post:

Hi,

I've done some extensive testing of the above environment with no
success. The basic idea is to restrict the url
http://localhost:8080/1/admin by a security-constraint (form or basic
auth), and have it forwarded to IIS as the url:
http://localhost/1/admin, preserving tomcat's form or basic
authentication mechanism.

First of all, redirecting of directory without security-constraint works
fine, i.e. http://localhost:8080/1/ gives the same as
http://localhost/1/

When trying this without the isapifilter directly to port 8080,
everything works fine, i get my basic auth dialog and i can login. But
if i try http://localhost/1/admin/ via IIS instead, i immediately get an
error 403 (Forbidden). I've traced this to probably being an AJP13
error. The Ajp13-log during this request shows:

-------------------------------------------------------
[Ajp13] === BaseRequest ===
method          = GET
protocol        = HTTP/1.1
requestURI      = /1/admin/index.jsp

....
------ snip... -------
....

cookies         = === Cookies ===
Cookie JSESSIONID=2862D7C5E9B5B05452C9BA4F8BBF9D6B ; 0 null null

jvmRoute        = null
=== AjpRequest ===
jvmRoute        = null

[Ajp13] sendHeaders()
[Ajp13] status is:  403(Forbidden)
[Ajp13] send()
[Ajp13] sending msg, len = 35
[Ajp13] doWrite(byte[], 0, 735)
[Ajp13] send()
[Ajp13] sending msg, len = 743
[Ajp13] finish()
[Ajp13] send()
[Ajp13] sending msg, len = 6
[Ajp13] recycle()
[Ajp13] receiveNextRequest()
[Ajp13] receive()
-------------------------------------------------------

This shows that at least the auth cookie is recognized, but in a request
to the page without security-constraint, it shows the exact same thing,
except with status 200 (or 302). With cookie and everything.

I've even browsed through the Ajp13-code, and found that this error
might come from 2 or 3 places where constraints/roles and other stuff is
checked. 

Is this a bug, or are support for security-constraints simply not
implemented in Ajp13? Is the bug really in Ajp13, that is, will it be
the same thing if i try mod_jk and apache instead?

I've tried setting the tomcatAuthenticating-parameter in the
Ajp13Connector to both false and true with no result. I've tried both
tomcat 4.0.1 and 4.0.1b2 with the same result. 

Please help. :)

Many thanks in advance.

//Joakim



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>