Thanks Steven - yes, you read the problem correctly re: secured pages that are redirected to a login form and then sent back to the original request. I need to reread your suggestion closely to make sure I'm following everything, but I think you've provided a possible solution. It sounds like I need to make sure I can establish the servlet filter prior to having the container intercept the request that originated from index.html.
Jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 24, 2002 3:55 PM > To: Tomcat Users List > Subject: Re: determining URL selected prior to redirection for > j_security_check? > > > On Wed, Jul 24, 2002 at 03:39:54PM -0700, Mike Jackson wrote: > > If you're trying to do security you should remember that > the Referer header > > can be forged with little to no problem. > > The original question was: > > > From: Stadter, Jim [mailto:[EMAIL PROTECTED]] > > > Subject: determining URL selected prior to redirection > for j_security_check? > > > > > My index.html page contains three links, two of which require > > > authorization prior to access. I'm using form based > > > authentication, and would like to customize the login.jsp page > > > (which contains the j_security_check form) to provide an > > > indication of the original link that was selected from index.html. > > > Is there a way to determine the original link that was selected > > > prior to the container redirecting to login.jsp? > > It sounds like what you're trying to set up is a set of three > secured pages, which if the user tries to request them, they get > redirected to a login form, logged in, and then sent back to the page > they requested. Is this correct? > > If so, then the easy solution is to: > > 1) implement a servlet filter that requires the user to have a session > and the session to have an "authenticated" attribute object. > > The object you store in there could be a simple Boolean, or it > could be a user login object, or it could even hold more complex data > (like a list of all server pages, etc, that the user is allowed to > access, pulled from a user database). > > If the user doesn't have an "authenticated" attribute in their > HTTP session, the servlet filter adds a "requestedpage" attribute > containing the URL of the page the user requested, then redirects the > user to the login page. > > 2) in the login.jsp, after successful login, get the requestedpage > attribute and redirect the user back there. > > I'm not too familiar with login.jsp; you may need to add a > standard check for cookie support (i.e. try to get a session for the > user, if not able to, then direct the user to an error page instead of > to the login page). > > There are a variety of other ways you could do the same thing, > for example having the redirect-to-login-page use a GET-style argument > for the requested page, and then having login.jsp grab that and insert > it into the login form as a hidden variable. You'd have to add > something, then, to specifcally verify that the requested page is > something the user is allowed to access, to avoid poisoned inputs. > > (poisoned inputs are still an issue with the filter/session > approach, but since the filter is less closely coupled to the > login.jsp, it always gets a chance to veto requests for pages the user > isn't allowed to get). > > Steven J. Owens > [EMAIL PROTECTED] > > "I'm going to make broad, sweeping generalizations and strong, > declarative statements, because otherwise I'll be here all night and > this document will be four times longer and much less fun to read. > Take it all with a grain of salt." - Me > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
