Cross Page Posting without PreviousPage in ASP.NET 2.0

That's one of those moments when one realizes that is using techniques from the pre-.net age thinking they are edgy :)

Hi Fritz, I just wanted to point out that in order to get values from the Request collection you'll have to use the "name" client-side attribute of the control, which is retrieved using its UniqueID property in place of ClientID, which differ only in the fact that ClientID has "_" to while UniqueID has "$".

Sergio - yes, it is funny :)

Simone - thanks, you're quite right, UniqueID is the property to use.

-Fritz

As caveats go, this is one you might drive a bus through. The client-side ID for the control can change as the structure of the originating page changes. Worse yet, when you retrieve the form variable value through the Request, the compiler is unable to detect the disconnect between the previous page and the target page. Your users will discover this problem before you do.

Perhaps you'd be better off using this technique only with the HTML controls. I can't imagine its worth the risk with the regular ASP.NET controls.

Moreover if you use MasterPage, things gets more complicated. Worse if you use Cross page post back with Gridview inside MasterPage!!

Thanks for the tip Fritz.

Add item to SharePoint list but returning to another
location [Via: Serge van den Oever [Macaw]
]...

Hello Fritz,

I wonder if something like this is feasible:

After reading this URL: http://www.codeproject.com/aspnet/persistentstatepage.asp, about rehydrating an _entire_ page state I wondered if the filter module you wrote that strips tracing output could be used instead to make this process easier.

The problem is that I want to intercept post backs that come from timed out sessions and require the user to login again. I want the post-login event to take place seamlessly as if the user had never timed out.

I'm migrating an ASP app that does this quite flawlessly with hidden form fields, but the approach in the code project article seems like a lot to go through if a filter could somehow suffice.


This is how the ASP currently works:

User is sitting on ChangeEmail.aspx page.
User fills in new email address with mynewaddy@mynewisp.com
User takes walk with buddy and sits too long and session expires.
User presses "Continue" button (to invoke a btnChangeAddress_Click event, of course) and expects to see confirmation of newly updated address.
System presents Please Login prompt instead of confirming the address change!
User logs in.
System presents the "Thank you, your address has been updated!"

So, how do achieve this in ASP.NET? One way would be to do what that article above says. But, could it be easier with a filter?

Assume the ChangePassword.aspx page is a master page or something that has a hidden panel with the login prompt.

The other panel is the content panel which contains the email address textbox.

When the page gets the incoming request, it sees that it is _NOT_ authenticated, and so it stores the contents of the Request.Params collection into a hidden form field and hides the main content panel (is this even possible though if the event handler inovked is targetting a control within that panel?)
The page renders the login control along with the persisted page state.

User enters UN and PASSWORD and submits form.

Now, the login control logic reauthenticates the user, but it also sets an item on HttpContext.Current.Items to contain the persisted state.

Instead of calling Response.Redirect to force a client side redirect, it calls Server.Transfer to itself.

Now, at this point, a filter reads the incoming request stream and scans it for the presence of the special post data var named "ReplayPageState" or something like that.

If it finds this present, it extracts the content of just that variable and then reconstructs the original posts pay load of the request that triggerred the authentication failure. Since the user is now authenticated, the request will essentially be "replayed" exactly as it was when the reauth occurred.

This is all off the top of my head right now, and I'm not sure that Server.Transfer would work in this way, but if it sounds at all feasible and more efficient than the code project approach, let me know what you think...

Thanks,
Josh

If so, it reads the contents of the Request.Params collection and sets it into a Hidden form field within a Panel
If the request is not authenticated, and is targetting a Handler that requires authentication, then the filter could extract the POST content and set it in the Context.Items collection and then when the page loads it would check for the presence of this item and populate a hidden field with all the data, once it gets posted back and the user successfully validates, then a new request gets created that repopulates

Great article. Question though... How do you retrieve the values of form fields that are located on a prevoius page and are within a ContentPlaceholder section of that previous page which also uses a Master Page? The page using the posted values does not use the Master Page. For some reason I can't seem to get the posted values of the form fields. Thanks!

I have same problem as Jason described, use Session Variable is cumbersome, but seems to work within a ContentPlaceholdr section; would like to use previous page if possible. Thanks for the great solutions / ideas I find here.

Jason, as 'randomfactor' points out, this technique can be quite fragile with server side controls contained in any parent controls (like contentplaceholders or panels) since the generated ids can so easily change.

In general I would stick with the technique of exposing properties from a previous page and accessing them via a strongly-typed reference to the PreviousPage property. This will always work, and as long as the previous page isn't doing anything excessively expensive up through Load, the overhead is worth it.

My point to this post was just that it works conceptually, and may be of interest if your pages are simple enough.

Josh - sorry, I don't have the time to review your complete scenario right now. Perhaps someone else can comment.

Thanks,
Fritz

hi jason,
Yr problem can be solved if you put the
<% @PreviousPageType VirtualPath="~/yoursourcefile.aspx" %>

directive in yr destination page.

But how to achieve it when i have 2 content page s of single master page ?

plz suggest if anyone knows.

This is how I handled page-to-page posting in ASP.NET 1.1 (i.e. make the viewstate disapear via client side javascript). Things work fine until you have ASP.NET generating ids for you because you have controls inside other controls etc.. It becomes a very fragile situation. I would stick to cross page posting via PreviousPage property. After all, cross page posting with PreviousPage it isn't any worse than postback and Response.Redirect.

It's a interesting solucion, but what do you do when you use an anchor tab to navegate to target page??..how do you cath the values???

about the question of the controls in the place holder, the solucion is getting the name of the control generated in the html and calling this control. It situation happens because the place holder chance de names of controls before it will be show in the HTML. the same situation happens with other container controls as datagrid or repeater.

Sorry for my english. it isn't well.

<script language=javascript>window.location.href='sam.aspx'</script>

Great idea. I was struggling to get the previous page to work, possibly because I was collecting the value from a user control in the master page!? Anyhow, I simply looked up the name in the HTML source, did a request.form and problem solved.