Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 58444 invoked from network); 11 Aug 2002 01:30:04 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 11 Aug 2002 01:30:04 -0000 Received: (qmail 1740 invoked by uid 97); 11 Aug 2002 01:30:13 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 1721 invoked by uid 97); 11 Aug 2002 01:30:13 -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 1709 invoked by uid 98); 11 Aug 2002 01:30:12 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Subject: Re: Problems with * From: Alexander Wallace To: Tomcat Users List In-Reply-To: <20020810130035.K38240-100000@icarus.apache.org> References: <20020810130035.K38240-100000@icarus.apache.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 10 Aug 2002 20:35:22 +0100 Message-Id: <1029008122.13736.75.camel@debnomo1> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Thankyou criag, your explanation is very clear. I have / right now, and though I seem to be getting the result I was expecting (I see the requested url with servletPath, and when i do the forward to the jsp, I do get the content of the jsp), I think i should follow your advice, i don't want to run into trouble later. I should check out filters and realms... I hope is not too hard :/ Thanks again! On Sat, 2002-08-10 at 21:06, Craig R. McClanahan wrote: > > > On 10 Aug 2002, Alexander Wallace wrote: > > > Date: 10 Aug 2002 13:56:15 +0100 > > From: Alexander Wallace > > Reply-To: Tomcat Users List > > To: Tomcat Users List > > Subject: Re: Problems with * > > > > Ok, but what I mean by access rights are a set of very custom > > permissions (existing in a database table) givent to different roles > > asigned to users of my web app, is that also handled by filters? > > > > Also, at this point I my servlet does receive requests (let's say > > /login) and checks if the users (in this case by providing an id in the > > url) is trying to log in into a valid "company" in the web app, and if > > so, I use a forward to a jsp that actually shows the login form and > > let's them log in. I'm not sure if you meant I was not going to be able > > to serve anyghing from my servlet, but i do. > > > > I'm I all confused then? I'm sorry if i sound too newbie... I am tho :/ > > > > Lets assume that you map your access-checking servlet to "/*". > Your user asks for the URL: > > http://localhost:8080/myapp/foo/bar.jsp > > and, because of the mapping, it is sent to your servlet. Your servlet > receives a servletPath of "" and a pathInfo of "/foo/bar.jsp", so you > check the access restrictions for that page and say "OK, go for it". > > Now, you try something like this: > > String pathInfo = request.getPathInfo(); > ... validate that accessing pathInfo is ok ... > RequestDispatcher rd = > getServletContext().getRequestDispatcher(pathInfo); > rd.forward(request, response); > > So what happens when you execute this? > > If you think it's going to execute your JSP page, you're going to be very > unpleasantly surprised. Why? Because the "/foo/bar.jsp" path is mapped > back to your access control servlet, due to the "/*" mapping. You end up > with an infinite loop, terminating ultimately in a stack overflow. > > This is why any attempt to use a servlet for access checking, followed by > a forward, is doomed to failure. PLEASE go read up about filters -- this > is one of the things that filters were designed to enable. > > Craig > > > > On Sat, 2002-08-10 at 18:59, Craig R. McClanahan wrote: > > > > > > > > > On 10 Aug 2002, Alexander Wallace wrote: > > > > > > > Date: 10 Aug 2002 12:17:03 +0100 > > > > From: Alexander Wallace > > > > Reply-To: Tomcat Users List > > > > To: Tomcat Users List > > > > Subject: Re: Problems with * > > > > > > > > What I need to be able to do is to make sure, that every request, for > > > > any page has enought rights to view the page and use it, So i thought of > > > > using a servlet as a controller. If I understand correctly what you > > > > talked about in this and your previous post, using the servlet mapping > > > > to "/" will not work at some point. > > > > > > > > I'm not that experienced yet in these matters, could you ilustrate to me > > > > a bit why this won't cut it? > > > > > > > > > > Using a *servlet* for your purpose (checking access rights) will not work > > > at all -- see my previous post for why you should use a Filter instead. > > > > > > The problem with the "/" mapping in particular is that this mapping is > > > assigned, by default, to a servlet that serves static content. So, when > > > you make a request to a URL like: > > > > > > http://localhost:8080/myapp/index.html > > > > > > you generally won't have a servlet mapped to this -- and Tomcat assigns it > > > to the default file-serving servlet, which serves the "/index.html" static > > > resource from your web application for you. > > > > > > If you map a servlet to "/", you have just *replaced* the standard > > > processing, because Tomcat will map the request to your servlet instead of > > > the standard one. Now, let's assume that the user has the rights they > > > need to access that resource and you want to let them have it. What > > > should your rights-checking servlet do? > > > > > > That's right ... you're stuck. There is no way to ask Tomcat to serve the > > > resource, because there is no longer any mapping for the default > > > file-serving servlet. > > > > > > The answer is to use a Filter instead, because a Filter can examine a > > > request *before* it is given to a servlet, and either intercept it (not > > > enough access rights) or pass it on (access rights are fine). > > > > > > Do some google searches on "servlet filter" and you will find pointers to > > > some articles about how they work. > > > > > > > Thank you! > > > > > > Craig > > > > > > > > > > > > > > On Sat, 2002-08-10 at 00:40, Craig R. McClanahan wrote: > > > > > > > > > > > > > > > On Fri, 9 Aug 2002, Todd Kaplinger wrote: > > > > > > > > > > > Date: Fri, 09 Aug 2002 17:43:36 -0400 > > > > > > From: Todd Kaplinger > > > > > > Reply-To: Tomcat Users List , > > > > > > kaplinger@Alum.Bentley.edu > > > > > > To: tomcat-user@jakarta.apache.org > > > > > > Subject: Re: Problems with * > > > > > > > > > > > > define a servlet mapping of just "/". this is the default servlet mapping. > > > > > > > > > > That's still not going to work for what the proposed use case was -- > > > > > because you've just disabled the default file-serving servlet that serves > > > > > static content. > > > > > > > > > > Craig > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > > > For additional commands, e-mail: > > > > > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > For additional commands, e-mail: > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > > For additional commands, e-mail: > > > > > > > > > > > -- > > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- To unsubscribe, e-mail: For additional commands, e-mail: