On Tue, 25 Mar 2003, Steven J. Owens wrote:
> Date: Tue, 25 Mar 2003 03:54:23 -0500 > From: Steven J. Owens <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: Re: Problem with Bookmarking a Login Page > > On Sun, Mar 23, 2003 at 05:10:43AM -0800, Mike Duffy wrote: > > Does anyone know of a Struts work around for the problem with Tomact > > in bookmarking the login page for container managed security? > > I believe, based on past conversations here, that Struts has its > own security filter solution to use, instead of standard J2EE > security. > That is not actually true. There are alternative solutions to container-managed security which work fine with Struts (such as the securityfilter project at SourceForge), but they are by no means specific to Struts. > > There was a brief thread on this issue about a month ago > > [http://www.mail-archive.com/[EMAIL PROTECTED]/msg59734.html] > > > > There is a SourceForge project called SecurityFilter that can be used > > to replace Tomcat's container managed security, but it would be nice > > to be able to work with Tomcat. > > I built my current project with standard J2EE security realms, > and currently plan to tell my users "don't do that." I do have a > vague hope, that I will one day get around to exploring, of setting up > a servlet filter that intervenes *before* the security realm gets > invoked, and filters out direct requests to the login page, forwarding > them to the main system page. However, I haven't even had a chance to > look into this, yet. > > > Has anyone tried to call "j_security_check" directly from an Action > > class? Once you can authenticate a user you would be able to get the > > roles for that user. > > > > Is there a way to set up a JDBC Realm purely in Struts? I did not see > > any information on this in a quick scan of the documentation. > > > > Hopefully, the good people working on Tomcat see this as a bug that > > needs to be fixed. > > As far as I've been able to determine, looking at the archives, > the answer is "broken as designed", i.e. the spec is broken but tomcat > is implementing the spec (which, since tomcat is the reference > implementation, I can't really fault them for). The upshot is they > won't change it until the spec changes (and hopefully specifies a more > reasonable solution). > > > Quote from a recent thread in the Tomcat news group: "I wish that > > there was a legitimate configuration change to enable you to bookmark > > a login.jsp page--such as a j_success_url parameter which instructs > > Tomcat where to send users if not doing an automated login process." > > > > Another user stated, "...I simply just can't believe that there are > > Tomcat instances out there in a live production environment with > > configured realms that suffer from this problem. Surely there must be > > something...." > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg77974.html > > If you can figure out a way to have a filter intercept requests > for the login page, that'd do the trick. The alternative would be to > patch and build your own variation of tomcat, with code to deal with > this specific situation. So you'd have a bit of extra work upgrading > to new versions of tomcat... > > Hm... I wonder... if you put the login page *outside* the > security realm, would that allow you to have the login page itself > redirect to a more appropriate page, if directly invoked? I'll have > to crack open the j_security_check class (can't remember, offhand at > the moment, what's it's called) and see if there's some parameter it > sets when it intercepts a request and forwards it to the login page. > If it does set a parameter, checking for that would be a good test to > see if the user directly invoked the login page. > > 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 at http://darksleep.com > The hard-nosed answer -- if you have users trying to bookmark the login page, switch your app to BASIC authentication (where there is no such thing as a "login page" that can be bookmarked) instead. The login page should be considered to be a part of the container, not a part of the application; the container displays it only when an unauthenticated user first requests a protected resource -- exactly the way that BASIC authentication works in all web servers. The more realistic answer -- the case where users might want to bookmark the login page so they can get to it immediately -- is only one of many hundreds of potential use cases for authentication. The servlet spec does not currently provide any portable mechanisms to support this use case -- any short term solution you come up with (in Tomcat's case, that probably means modifying the Tomcat source code, because the "j_security_check" URL is only enabled when a container-managed login is currently in progress) is going to be container specific. You are far better off training users to bookmark the first page within the protected portion of your webapp instead. IIRC, Tomcat 5 will attempt to forward to the login page (instead of a redirect), so that the actual URL won't be visible to users (and therefore susceptible to bookmarking). The downside for app developers is that you wil need to ensure that relative URLs (such as for images) work no matter what URL is actually requested -- the easiest way to do this is to have a <base> element in the <head> section of the page. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
