Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 14712 invoked from network); 15 Nov 2001 20:02:05 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Nov 2001 20:02:05 -0000 Received: (qmail 24029 invoked by uid 97); 15 Nov 2001 20:00:26 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 24013 invoked by uid 97); 15 Nov 2001 20:00:26 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 24000 invoked from network); 15 Nov 2001 20:00:25 -0000 Date: Thu, 15 Nov 2001 11:58:58 -0800 (PST) From: Richard Troy To: Tomcat-user Subject: Re: blocking access using filter (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Date: Wed, 17 Oct 2001 16:41:33 -0700 (PDT) From: Craig R. McClanahan Reply-To: tomcat-user@jakarta.apache.org To: tomcat-user@jakarta.apache.org Subject: Re: blocking access using filter On Wed, 17 Oct 2001, Taavi Tiirik wrote: > Date: Wed, 17 Oct 2001 22:47:53 +0200 > From: Taavi Tiirik > Reply-To: tomcat-user@jakarta.apache.org > To: tomcat-user@jakarta.apache.org > Subject: blocking access using filter > > Hey, > > I need more sophisticated access control for certain > documents than JDBCRealm provides. These documents > reside in separate directory tree and they are > served by standalone tomcat 4. I have mapped an > 'access control filter' to listen to all requests to > this directory. Filter should behave like this: > > 1. If user is not logged in or if the session has > timed out then it should open login page and after > successful login it should try to access the very > same request (ie. the same document). > > / I am using getRemoteUser() to determine if user > is logged in. / > > 2. Filter performs a database lookup and decides if > given user can access this document. > > / This step is easy and I can live with extra > overhead needed for database query. / > > 3. If user does not have rights to access this > document then filter should send error 404 (no such > document). > > / This can be achieved using: > response.sendError( HttpServletResponse.SC_NOT_FOUND ); / > > 4. Do nothing... ie. user will get this document. > > / 'do nothing' actually means calling next filter in > chain like this: > chain.doFilter( request, response ); / > That's a pretty impressive amount of learning-by-doing! > > I have figured out all steps but the very first one. > What should I do in filter in order to make tomcat > to use it's standard authentication mechanism > (JDBCRealm, form based login in my case) so > the user could log in and still get required document? > What you've got so far doesn't really correspond to JDBCRealm, which is just a way to tell Tomcat how to look up users. I don't quite see why you need to modify the standard form-based login mechanisms, either. Can't you just use the standard form based login for triggering authentication? This would be as simple as a security constraint that looks like this:

The Entire Webapp

The "/*" URL pattern means that every single URL inside this webapp is protected by the constraint. The "*" in role names mean that it doesn't matter what role(s) the user has -- every request requires an authenticated user. Therefore, by the time your filter is invoked, getRemoteUser() will return the username you are looking for, and you can impose any *additional* constraints that you need to. Form based login already does the rest of what your step (1) includes - it remembers the page that the user asks for (if it switches them to the login screen), and automatically "replays" it once authentication is done. If you really did want to modify the Tomcat authenticator, you would need to turn this filter into an implementation of the "org.apache.catalina.Valve" interface, which is conceptually pretty similar to a Filter. Valves (including the standard one used for authentication) are invoked before the Filters (and the ultimate servlet) belonging to your web application are invoked. > Please, any help is appreciated. I will happily donate > this filter back to the group if I get it working and > if there is interest. > > thanks in advance, > Taavi > > Craig -- To unsubscribe: For additional commands: Troubles with the list: