views:

630

answers:

3

While this is similar to other questions, I've been unable to figure this out, and I feel pretty dumb for not knowing how to do it.

1) I can't use the PostbackURL property for the button click.

Basically what I need to do is, when a user clicks a button, I need to post data to a separate URL. That data is not found within the form. I need to add the data programmaticaly in the code behind.

So the user would click "Send". I would then add the user's email, firstname, lastname to a namedvaluecollection I'm assuming, and then post that to a certain URL.

My question is, how the heck do you do that? I've been unable to find anything online so far that clearly states how this is done, without creating a new HttpWebRequest.

EDIT PER COMMENT BELOW:

Basically we are integrating our membership with a separate application, and this has worked before. Unfortunately their tech support isn't helping much.

Basically a user is on their site and tries to do something which requires you to be logged in.

User is redirected to my login page. User enters credentials. If the user authenticates, I post their information (name, email etc...) to a specific URL. That URL will create the user on their end (if they don't exist) and/or redirect them to whatever URL they were trying to access the first time.

I have this working, however since I'm creating a new HttpWebRequest object, the redirect on their end is not working.

I could do this all in a query string, but with the amount of data being posted I think I'll exceed the URL character limit.

A: 

if the user is always posting to another page, what you could do is the following.

1.) Add the information that you are going to add to hidden fields on the page, that way it is there. 2.) Then modify the "Action" on the form object to do a direct post to the other page.

Now depending on implementation that may or may not work

Mitchel Sellers
I can't add the fields to the page because the fields only get populated once the user clicks the submit button. Basically it's a login feature. The user logs in, the user object is populated, then those properties are then posted to a different URL.
Jack Marchetti
+1  A: 

You could take a look at the Server.Transfer method. This will (on the server, not the client) transfer all execution to the new page, including current forms and querystring collections, and send the results of that page back to the client browser.

However, reading the last part of your question implies that you're probably not transferring to a page on your server are you? In which case this probably won't work for you.


Edit to respond to comment

Could you clarify what you want the user to see then from your point of view?

  • They are on www.example.com/someform.aspx, they fill in the form, and press submit.
  • The form is submitted back to the server (someform.aspx), some processing happens server side, and then the original form details, along with some additional fields are POSTed to www.someotherserver.com/anotherform.xxx
  • What should the user be shown at this point? The results of the page on someotherserver.com, or something else from your server?

At some point you are going to need to create a new request to the 3rd party site - that's either going to be from the client browser via JavaScript, through something like Response.Redirect, in which case you're limited to query-string fields, and the user will know they've been sent somewhere else, or behind the scenes using an HttpWebRequest.

Personally, I just don't think it can be done how you want I'm afraid.

Zhaph - Ben Duguid
No, I'm posting to a completely separate application [URL]
Jack Marchetti
A: 

Make a second form, which has the postbackurl set to the target site. This could be another page, or a hidden second form in the same page.

Once the primary form is submitted by the user, you fill the (hidden) fields of the second form from code and submit it using javascript form.submit() on pageload (insert the javascript from codebehind).

Ofcourse, it's easier to just Response.Redirect, which amounts to a initiating a GET from the browser.

May I point out to you that POST variables can be easily manipulated by users too? It's less obvious than manipulating the URL, so there's somewhat of a slowdown here for non-technical users.

But there's NO security and NO data protection in POST!

Endorf