struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fzli...@omnytex.com
Subject RE: Accessing my form from an included page
Date Thu, 23 Dec 2004 15:16:47 GMT
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: fzlists@omnytex.com [mailto:fzlists@omnytex.com]
>> 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: user-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: user-help@struts.apache.org
>> >
>> >
>>
>>
> 
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


Mime
View raw message