Thank Craig. I think the correct way to "educate" users is to create a specific error-page for the 400 error which says something like, "You may have reached this error page from the login page......", and to have a link on that page to the default secured page (which means the login page would be displayed when the user clicked on the link).
Can you confirm that j_security_check can only be called by the container in response to a browser request, meaning that it is not possible to call j_security_check directly or to "force" a call by forwarding or redirecting to a secured page? This would rule out any attemps to create a filter based on a call to the login page. Also, it doesn't look like there are any methods in the API to set users and roles in the session that could then be available to the methods getUserPrincipal(), isUserInRole(), etc. This would mean that if you are going to come up with your own A/A framework you have to bypass the container A/A completely. Is that correct? Mike --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > > > 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] > __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
