On Thu, December 23, 2004 9:49 am, Paul McCulloch said: > Frank, > > Although your solution would work I'd be apprehensive about any solution > which involves doing anything manually at the start of each action. I'd > suggest that anything that needs to happen for each & every action is > better > suited to a modified RequestProcessor, or a Filter.
I couldn't agree more. I was just outlining what I had done in one particular situation. There were reasons for doing it that way at the time, mostly because we were in a rapidly-changing envirinment and weren't sure what the final environment would look like, so we didn't want to do anything that might tie us to a particular server environment. Plus, we weren't up to a servlet spec that allowed filters, so it didn't matter anyway :) Bottom-line: your 100% right, a filter is I think the "right" answer for such a thing. > As you want to deal with all requests - not just actions, I'd suggest that > a > Filter would be the way to go. Bingo :) Absolutely agreed. > My apologies if I'm trying to teach you to suck eggs :-) Not at all! If I didn't know about filters or hadn't thought of it you would have done me a service informing me, so it's all good as far as I'm concerned :) > Paul > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Sent: 23 December 2004 14:41 >> To: user@struts.apache.org >> Subject: RE: Accessing my form from an included page >> >> >> On Thu, December 23, 2004 9:13 am, Donie Kelly said: >> > [Donie Kelly] Hi Guys >> > >> > OK, I ran through most of what your are telling me and must >> first thank >> > you >> > all for the detailed responses. >> >> You spawned an interesting thread! The seemingly simple >> questions are usually the ones that do that though. :) >> >> > 1) I want to check I have a valid session so that I know >> the objects I >> > have >> > been carrying through the session are still there. It they >> are not, I want >> > to reestablish them by redirecting back to some starting page which >> > initialises the session. >> >> I can tell you the way I've done this in the past... Firstly, >> note that the best way is with some plug-in to your web >> server (or app server) that externalizes security, something >> like Netegrity for example. This would handle expiring >> sessions and such as you want, redirecting to some logon page >> presumably. >> >> In the absence of that though, what I've done is to have an >> ActionHelpers class... This class contains two methods, >> start() and finish(). start() is called at the start of each >> Action and finish(), you guessed it, is called right before >> returning the ActionForward. >> >> Let's ignore what finish() does because it's not applicable >> here... start() however is... The first thing it does is >> calls checkSession() (my own method) that verifies if the >> session is valid or not, and redirects to the logon page if it's not. >> >> That takes care of one piece of the puzzle... the other is >> what happens if someone accesses a JSP directly? All I do >> here is call checkSession() directly. If it's invalid, the >> page renders a redirect. So, all the JSP's have a structure >> along these lines: >> >> <% if (!ActionHelpers.checkSession()) { %> >> <HTML><HEAD><TITLE></TITLE> >> <META HTTP-EQUIV="refresh" >> CONTENT="0;URL=http://www.mysite.com/logon.do";> >> </HEAD><BODY</BODY></HTML> >> <% } else { %> >> ... The actual page goes here >> <% } %> >> >> That does the trick. I'm in NO WAY saying this is >> industrial-strength security, but it gets the job done. In >> the environment I do this in, security isn't an issue though, >> so this is fine. Also, it wouldn't be trivial I think to >> hack this anyway since you have to get a valid session on the >> server at some point that matches what's on the client, and >> assuming that can only be done through some logon procedure, >> it should be not completely insecure :) >> >> > 2) Need to put page navigation in the header.jsp page to >> make it easy to >> > navigate. I guess I will be putting stuff in the session to >> make so I was >> > going to use the form to return the breadcrumb name. Is >> this a good way to >> > do it? >> >> I would suggest looking for a canned breadcrumb solution. >> There was a recent thread about just that, and some existing >> solutions were mentioned. >> >> If your going to build your own, you need to determine what >> information you really need to construct your nav bar. I >> doesn't sound like you need access to the Form Bean, as I had >> thought you were asking originally (maybe you were, maybe I >> misunderstood... doesn't really matter I guess :) ). Sounds >> like what you really need is the Action path for all the >> pages that have been visited in order. >> >> I would myself be thinking of a linked list structure, stored >> in session, with each item holding the mapping path. That >> should be all you need to construct a breakcrumb path. >> >> But again, no sense reinventing the wheel... Solutions for >> this exist already. >> >> > That's it really. >> > Donie >> > >> > -- >> > No virus found in this outgoing message. >> > Checked by AVG Anti-Virus. >> > Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: >> 22/12/2004 >> > >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> > > Axios Email Confidentiality Footer > Privileged/Confidential Information may be contained in this message. If > you are not the addressee indicated in this message (or responsible for > delivery of the message to such person), you may not copy or deliver this > message to anyone. In such case, you should destroy this message, and > notify us immediately. If you or your employer does not consent to > Internet email messages of this kind, please advise us immediately. > Opinions, conclusions and other information expressed in this message are > not given or endorsed by my Company or employer unless otherwise indicated > by an authorised representative independent of this message. > > WARNING: > While Axios Systems Ltd takes steps to prevent computer viruses from being > transmitted via electronic mail attachments we cannot guarantee that > attachments do not contain computer virus code. You are therefore > strongly advised to undertake anti virus checks prior to accessing the > attachment to this electronic mail. Axios Systems Ltd grants no > warranties regarding performance use or quality of any attachment and > undertakes no liability for loss or damage howsoever caused. > > > --------------------------------------------------------------------- > 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]
