No problem. As I was typing it, though, I started to worry that I'd gotten ahead of myself. Is there an easier way to do this? Especially a way that is immune to proxy server stripping of the referer header? Jason seemed to indicate something about a breadcrumb interceptor, but I'm not sure how that would work (especially if you try to use it to remember all of the params that were set).
Note too that this isn't the solution whenever you want to use the referer header. This is for when you want to "bookmark" a place to come back to, with all of the params remembered, so that you can do other things like a confirm page in the meantime. A lot of the time, a simple redirect to the referer will suffice, without any of the source aware stuff. For example, for an add or a delete action, I usually have to go to some page first before the actual add or delete (for add, I have to go to a form; for delete, I go to a confirmation page). In both cases, I want to return to the page from which the link was clicked. Other times, if I just want to come back to the same page immediately without going anywhere else, and I don't want to hard code the link, I use a referer action like in webwork 1.3. Let me know if you need more info for the wiki stuff. Though I'd hate to have this in there and then find out there's an easier way.... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Porter Sent: Friday, February 13, 2004 3:34 PM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] WW2 Return To Page - THANKS DREW 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
