+1 The other justification was defensive programming. If they tried to open the page directly, it would blow up, since the expected objects would not be in the request. But, since then, we've stopped linking to pages directly, so the tag is a feature without a cause :)
If we want to demonstrate this and that, then we should setup an actual cookbook application, like the one Steve Raeburn started. * http://www.ninsky.com/struts/index.html Otherwise, any example application should be a best-practice example of how we would write the application in practice. For MailReader, the tag is redundant and can just be removed. The Actions already check for the user bean and forward to logon if it's missing. SecurityFilter is cool, but it might be overkill for an application of this size. If I were to gong to make changes, I'd probably move it all to a DispatchAction and reduce the login checks to a single method call. (While putting in a remark to consider SecurityFilter if additional Actions are added in a subsequent iteration.) -Ted. On Thu, 24 Feb 2005 09:55:58 -0500, James Mitchell wrote: > If I recall correctly, the app:checklogon tag was initially written > to simply demonstrate how to write a custom taglib. However, I am > of the opinion that (while intentions were good) that tag should be > removed as it demonstrates what I would call a "bad practice" wrt > j2ee security. We could replace that functionality with something > like security filter. > > Yes, I am volunteering ;) > > Your thoughts? > > > -- > James Mitchell > Software Engineer / Open Source Evangelist > EdgeTech, Inc. > 678.910.8017 > AIM: jmitchtx > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
