POST to Non-ASP.NET Site

J

Jonathan Wood

I am trying to simulate a post to a page that is on another server and is
not implemented in ASP.NET.

I've found some examples for this using WebRequest. That code appears to
work and the data is getting posted to the intended site.

However, I need to redirect to that site, bringing the target site up in the
browser just as though I had clicked a Submit button within a <form> tag.

I'm finding surprising little about doing this on the Web. I'm surprised
others aren't running into this.

Thanks for any tips.
 
G

Guest

I am trying to simulate a post to a page that is on another server and is
not implemented in ASP.NET.

I've found some examples for this using WebRequest. That code appears to
work and the data is getting posted to the intended site.

However, I need to redirect to that site, bringing the target site up in the
browser just as though I had clicked a Submit button within a <form> tag.

I'm finding surprising little about doing this on the Web. I'm surprised
others aren't running into this.

Thanks for any tips.

How Do I...Make a POST request?
http://samples.gotdotnet.com/quickstart/howto/doc/WebRequests/clientPOST.aspx
 
J

Jonathan Wood

Thanks, but I didn't see where that code redirected the browser to the POST
response.
 
J

Jonathan Wood

Thanks, but I don't see where that link discusses redirecting the browser to
the POSTed results.
 
J

Jonathan Wood

Yeah, I did that. From what I can tell (I haven't been using .NET that
long), it appears to be a console app that simulates a POST. It then prints
the resulting HTML to the console.

Printing the result in a console app is not the same as redirection. As
indicated, I want the browser to load the resulting page so the user can
navigage from that page. I guess I could sent the results to my page, but
things such as relative links wouldn't work.

I'm already simulating a POST. I got that working. It's the redirection I
can't find anything about.

Did I miss something?

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Anon User said:
Thanks, but I don't see where that link discusses redirecting the browser
to
the POSTed results.

Please click on the [View Source] link
 
M

Mark Rae [MVP]

It's the redirection I can't find anything about.

What you want is extremely simple, but involves an absolutely atrocious
hack! I have to confess that I've been watching this thread in the hope that
someone would post a much more elegant solution than the one I'm going to
post below (which I would then steal!), but it seems not...

So, with apologies to everyone, here goes:

<asp:Button ID="cmdPostRedirect" runat="server" Text="Post redirect"
OnClick="cmdPostRedirect_Click" />

protected void cmdPostRedirect_Click(object sender, EventArgs e)
{
Response.Clear();
Response.Write("<html>");
Response.Write("<head></head>");
Response.Write("<body onload=\"document.forms[0].submit()\">");
Response.Write("<form id=\"form1\"
action=\"http://www.remotesite.com/remoteform.aspx\" method=\"post\">");
Response.Write("<input type=\"hidden\" name=\"fieldn\" value=\"valuen\"
/>");
Response.Write("</form>");
Response.Write("</body>");
Response.Write("</html>");
HttpContext.Current.ApplicationInstance.CompleteRequest();
}
 
J

Jonathan Wood

Hah! That's an interesting approach.

Other than the annoyance of having the page flash before being redirected,
it does indeed appear to work.

Thanks for posting that--I appreciate it. But I do agree that a better
workaround really is needed.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

Mark Rae said:
It's the redirection I can't find anything about.

What you want is extremely simple, but involves an absolutely atrocious
hack! I have to confess that I've been watching this thread in the hope
that someone would post a much more elegant solution than the one I'm
going to post below (which I would then steal!), but it seems not...

So, with apologies to everyone, here goes:

<asp:Button ID="cmdPostRedirect" runat="server" Text="Post redirect"
OnClick="cmdPostRedirect_Click" />

protected void cmdPostRedirect_Click(object sender, EventArgs e)
{
Response.Clear();
Response.Write("<html>");
Response.Write("<head></head>");
Response.Write("<body onload=\"document.forms[0].submit()\">");
Response.Write("<form id=\"form1\"
action=\"http://www.remotesite.com/remoteform.aspx\" method=\"post\">");
Response.Write("<input type=\"hidden\" name=\"fieldn\" value=\"valuen\"
/>");
Response.Write("</form>");
Response.Write("</body>");
Response.Write("</html>");
HttpContext.Current.ApplicationInstance.CompleteRequest();
}
 
M

Mark Rae [MVP]

Other than the annoyance of having the page flash before being redirected,
it does indeed appear to work.

There are all sorts of ways round that...

1) Don't use a postback - instead, have an <input type="button"
onclick="location.href='myotherpage.aspx';" /> control, and don't have any
markup on myotherpage.aspx other than something saying "Please wait - about
to redirect you to...." The problem with that, though, is that the
name-value pairs are viewable if you do a View Source really fast...

2) Build the whole thing as an additional <form> - you can have as many
<form> elements on an aspx page as you like, so long as only one of them
runs server-side. Obviously, that's even worse than 1) in terms of
security...

3) Some fun stuff with <iframes> (not recommended...)

4) Use AJAX. Obviously, HttpContext is invalid during a callback, so you
can't just use Response.Redirect. However, there are ways round that too:
http://www.codeproject.com/Ajax/magicajax.asp

Etc...
 
J

Jonathan Wood

Mark,
1) Don't use a postback - instead, have an <input type="button"
onclick="location.href='myotherpage.aspx';" /> control, and don't have any
markup on myotherpage.aspx other than something saying "Please wait -
about to redirect you to...." The problem with that, though, is that the
name-value pairs are viewable if you do a View Source really fast...

Well, it's a bit messier. But the name/value pairs are viewable in my
non-ASP.NET version anyway. Probably not a problem but another reason why a
proper .NET solution might be an advantage.
2) Build the whole thing as an additional <form> - you can have as many
<form> elements on an aspx page as you like, so long as only one of them
runs server-side. Obviously, that's even worse than 1) in terms of
security...

I'm not sure I understand that. It appears that even a <form> that runs
server-side still appears in the final HTML. Since the spec says you can't
nest <form> tags, the only way I could see to do this is if you placed
everything outside of the main <form> of the page.
 
M

Mark Rae [MVP]

Well, it's a bit messier. But the name/value pairs are viewable in my
non-ASP.NET version anyway. Probably not a problem but another reason why
a proper .NET solution might be an advantage.

The solution I gave you is a proper ASP.NET solution...
I'm not sure I understand that. It appears that even a <form> that runs
server-side still appears in the final HTML. Since the spec says you can't
nest <form> tags, the only way I could see to do this is if you placed
everything outside of the main <form> of the page.

Correct.
 
J

Jonathan Wood

Mark,
The solution I gave you is a proper ASP.NET solution...

It's implemented using ASP.NET, but the redirection is accomplished via
HTML. As you seemed to be suggesting, being able to do this server-side
would make the information a little more secure.

This is the approach I was taking initially. I'm not thrilled with it.
 
M

Mark Rae [MVP]

It's implemented using ASP.NET, but the redirection is accomplished via
HTML. As you seemed to be suggesting, being able to do this server-side
would make the information a little more secure.

I've clearly either confused you, or have not explained properly...

With the solution I gave you, none of the dynamic form is rendered to the
client at all - that's the beauty of it. It's built up server-side, and then
redirected server-side. The first thing the client sees is the response from
the remote server...

In fact, this was the main reason I developed it - specifically, for PayPal
integration with ASP.NET...
 
J

Jonathan Wood

Mark,
With the solution I gave you, none of the dynamic form is rendered to the
client at all - that's the beauty of it. It's built up server-side, and
then redirected server-side. The first thing the client sees is the
response from the remote server...

Then why did I see the generated <form> page flash in my browser before
being redirected. (At least, in your original version of the code.)
 
M

Mark Rae [MVP]

Then why did I see the generated <form> page flash in my browser before
being redirected. (At least, in your original version of the code.)

No idea...
 
J

Jonathan Wood

Then why when I said "Other than the annoyance of having the page flash
before being redirected, it does indeed appear to work," you replied "There
are all sorts of ways round that..."

What did I miss?
 
M

Mark Rae [MVP]

Then why when I said "Other than the annoyance of having the page flash
before being redirected, it does indeed appear to work," you replied
"There are all sorts of ways round that..."

What did I miss?

Here's an example of it working with no page flash:

1) http://www.sanctuaryrig.co.uk

2) Click the logo to enter the site
(Yes, that's me with my other "hat" on - sorry for the self-promotion, but
it's the only example of this that I have on the public Internet...)

3) Click Merchandise

4) Click Add to cart

5) Click View Cart

6) Select a delivery location

7) Click Proceed to checkout

8) Click Make payment - this just redirects to PayPal - you don't have to
proceed any further than that if you don't want to... ;-)
 
B

Barrie Wilson

Jonathan Wood said:
Mark,


Then why did I see the generated <form> page flash in my browser before
being redirected. (At least, in your original version of the code.)

if I recall Mark's code, it was a series of Response.Write(...) statements
that would have been processed by the client browser, albeit with no client
content to display ... I understand Mark's statement that it's "built up
server-side" but I don't understand his comment that it's "redirected
server-side" .... the client gets <form> ... </form> block and *it* requests
the page in the action attribute ... it should happen quickly but to me,
this is happening on the client side, not the server .... where is the
output of those Response.Write statements going if not to the client?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,777
Messages
2,569,604
Members
45,217
Latest member
topweb3twitterchannels

Latest Threads

Top