Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7B101C1A5 for ; Tue, 29 May 2012 14:59:29 +0000 (UTC) Received: (qmail 42853 invoked by uid 500); 29 May 2012 14:59:26 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 42758 invoked by uid 500); 29 May 2012 14:59:26 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 42746 invoked by uid 99); 29 May 2012 14:59:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2012 14:59:26 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [193.75.92.156] (HELO mx.visma.com) (193.75.92.156) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2012 14:59:19 +0000 From: =?iso-8859-1?Q?Alexander_Landsnes_Ke=FCl?= To: Tomcat Users List Subject: RE: Tomcat filter behaviour Thread-Topic: Tomcat filter behaviour Thread-Index: Ac09n278Q4JcmrjsSKq7FA/jetKA4f//6SuA///RgsA= Date: Tue, 29 May 2012 14:58:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= So my expectations contain the only bugs in this instance :) Thanks. I suspected it might be something like that, but I hadn't seen anyt= hing about it. Now to work around the issue, we've been rather dependent on= how it worked in the past but I believe I understand why it had to change. Alex -----Original Message----- From: Konstantin Kolinko [mailto:knst.kolinko@gmail.com]=20 Sent: 29. mai 2012 16:10 To: Tomcat Users List Subject: Re: Tomcat filter behaviour 2012/5/29 Alexander Landsnes Ke=FCl : > I'm seeing some behaviour from Tomcat 7 that I'd classify as "funky" when= it comes to servlet filters. First off the technical setup > > JDK 1.7.0_03 (64-bit) > Tomcat 7.0.26 (64-bit) binaries > 4 instances of Tomcat share those binaries, each installed as a pretty st= andard windows service using service.bat. Their bin folder contains the req= uired files, tomcat-juli.jar and a setenv.bat as well as a renamed tomcat7w= .exe for convenience. > > The setup itself works like a charm, I can run webapps on all the above s= ervers and they all have their own ports for the connector, shutdown and aj= p. I also double checked that no application references catalina.home for c= onfig, they all check catalina.base. > The problem appears when I try to use the Waffle servlet filter to authen= ticate a remote user on one of the above instances. I ran it in a few diffe= rent scenarios, and the behavior leaves me puzzled. All the scenarios run w= ith the filter logging turned on, so it appears to behave correctly. > > 1) > I defined the and elements in the (shared) web.= xml for a tomcat instance, with /*. I tried havi= ng it both at the very start, and the very end of the file with the exact s= ame behaviour. The filter would only work correctly on the very root of the= tomcat server, so http://localhost:8180/. Attempting to navigate to any ot= her context would appear to trigger the Kerberos auth (HTTP headers contain= ed Authorization: Negotiate & what I believe is a Base64 encoded Kerberos t= icket), but the the remote user retrieved from the servlet would be null. > > 2) > I moved the config from the shared web.xml and over to a specific webapp = that needs the remote user. This works like a charm, more or less as expect= ed. without SSO. > > 3) > Moving the filter definition, but not the filter-mapping, to the shared w= eb.xml, and then mapping it in a context specific web.xml also works as exp= ected. The remote user can be retrieved from the servlet. > > The second setup, having Waffle defined in the context specific web.xml, = won't be an option for us in a production environment. Ideally the same war= file should be deployable to an environment with SSO and also without SSO.= It could be solved by two versions of the web.xml, but it's more of a last= resort. > We've got a similar setup, on an old Tomcat 6.0.26 test instance, where w= affle runs like a charm from the shared web.xml. A major difference here be= ing that catalina.base & catalina.home refer to the exact same folder. > > Is this behaviour intended? That a filter-mapping in the shared web.xml i= s disregarded in the contexts? Or am I seeing a bug of sorts here? I'll adm= it to my knowledge of the servlet spec is cursory at best, but this strikes= me as wrong. I've got a virtual server I can fiddle with if anyone has sug= gestions as to how I can "fix" this behaviour. > Yes, it is intended behaviour and Tomcat 7 here differs from earlier versio= ns. See explanation here: https://issues.apache.org/bugzilla/show_bug.cgi?id=3D51754#c1 You may also want to look at https://issues.apache.org/bugzilla/show_bug.cgi?id=3D52138#c4 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org