Drew! This was a great response! Im going to crank it into my code right now.
I am also, with your OK going to create a WIKI with this detailed out... most likely in the CookBook section. Mike ----- Original Message ----- From: "Drew McAuliffe" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 11, 2004 9:47 PM Subject: RE: [OS-webwork] WW2 Return To Page > I do stuff like this a lot. Unfortunately it relies on the referer header, > which I didn't know was vulnerable to proxy modification. Does anyone have > any docs on that? > > Anyway, here's how I do it: > 1) Actions that support this implement a SourceAware interface, which has a > getter/setter for a String "source" property. > 2) Links that want to start a process that will come back to the same page > use a "markSource" parameter set to true. For example, a link on a view page > to an "add" action would include "markSource=true" in the link URL. After > add completes successfully, it returns back to this same page. > 3) The action to which you are linking has a "SourceTrackingInterceptor" in > the stack. It detects if "markSource" = "true" in the "before" method (it's > a subclass of AroundInterceptor). If so, it accesses the source URL using > the referer header and stores it via setSource(), which is exposed via the > SourceAware interface. > 4) The page to which you link has a "source" hidden control on the form, so > that you can store the source URL. The action for this form calls your > SourceAware action. > 5) The SourceAware action has a result that can deal with sources. In my > case, I use a SourceAwareRedirectResult, which is just like a redirect > result EXCEPT that it first tries to see if "source" has been set in the > action. If it has, it redirects to that, which takes you back to the page > with the "markSource" link. If source hasn't been set, it redirects as > normal, to the configured "location" param, just like a normal > RedirectResult. That way, if source wasn't specified, you can have a default > result. > > An example of this is an add action. Items in an app can be added from > several pages, and you want control over where you go after a successful > add. It's even more important for deletes, since you can delete from a > detail page of a record in my app or from a list of items, which could be on > any page. There's no way to know at configure time where you should go after > a delete because you could have initiated it from one of many different > places. Technically speaking, I suppose you could have a configured result > for each possible place, but I've found that this approach makes it easier, > since you don't need to worry about results and you can freely include a > delete link anywhere you want without having to create a result. > > Here's a specific example that might explain how/why I found this necessary. > It was the main impetus to implement this mechanism, which I've since used > elsewhere: > -you're on a page with a list of items, each of which has a delete link. > -after clicking on the delete link, you don't just want the item to go away; > you need to confirm the deletion. So, your delete link is actually to a > delete confirm page, not to the action that actually does the delete. > -This confirm page is reached via a load action, that is source aware. It > also has a source tracking interceptor, so it knows that if the markSource > property was set when calling it, it takes the referer and sticks it in the > source property. It has to be a form, with a hidden control called source to > store the source information filled in by the interceptor. This makes sure > that it's available to the next action. > -After confirming, you chain to the delete action. It is also source aware, > and because you're chaining, the source property is taken from the form and > stuck into the delete action's source property. The delete action has a > source aware redirect result, so it sees that source was set, and then uses > that for your redirect. > > Does that make sense? Am I making things too confusing for myself? Am I > vulnerable to overeager proxy servers? Any input is welcome; so far I like > the solution but if there's an easier way without worrying about proxies I'd > be glad to implement it. I'm also curious if there's an easier way to do > this that I just missed in the rush to implement it. > > Thanks, > Drew > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Anthony Eden > Sent: Wednesday, February 11, 2004 11:50 AM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] WW2 Return To Page > > I don't think I'd trust the Referer header. It is probably better to pass a > parameter and if the parameter doesn't exist then to provide a default. > > Sincerely, > Anthony Eden > > Frank Febbraro wrote: > > >Can you use the Referer request header? > > > >That tells what page you just came from, be wary though as some proxies > >will strip that. > > > >----- Original Message ----- > >From: "Mike Porter" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Wednesday, February 11, 2004 1:46 PM > >Subject: [OS-webwork] WW2 Return To Page > > > > > > > > > >>Gang, > >>I have a WW page that I can get to from 2 different places. When the > >> > >> > >users > > > > > >>is done with the target page, they should return back to the correct > >> > >> > >calling > > > > > >>page. > >>In my WW XWork.xml file I currently have a dispatch mapping that > >>returns > >> > >> > >me > > > > > >>to only ONE page. Sort of hard coded. > >> > >>I was just about to implement a solution where I send a parameter to > >>the target page called returnToPage=pageA. The target jsp would put > >>this value into a hidden field. Then my Action would read this value > >>and use this value as the RETURN parameter for the execute() method. > >>I would then have dispatch mappings for both pageA and pageB... > >> > >>This approach seems ugly. Are there smarter ways of doing the same thing? > >>IE: determining dynamically what the dispatch should be based on where > >>the user was coming from? > >> > >>Mike > >> > >> > >> > >> > >> > >>------------------------------------------------------- > >>SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >>Build and deploy apps & Web services for Linux with a free DVD > >>software kit from IBM. Click Now! > >>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >>_______________________________________________ > >>Opensymphony-webwork mailing list > >>[EMAIL PROTECTED] > >>https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > >> > >> > >> > > > > > > > > > >------------------------------------------------------- > >SF.Net is sponsored by: Speed Start Your Linux Apps Now. > >Build and deploy apps & Web services for Linux with a free DVD software > >kit from IBM. Click Now! > >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > >_______________________________________________ > >Opensymphony-webwork mailing list > >[EMAIL PROTECTED] > >https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > > > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
