Comment On Directing a Redirect

I totally know why the programmer did this (at least I think I know). If you have all the information entered into the form and then submit it, you'll immediately go to the submitting page. If it takes more than a second or two for that page to process, it's more user-friendly to have a page that says "Please wait while we access your account" or whatever. What you need to do is submit the form data to the "Please wait..." page, and then have THAT page submit it to the page that will read in the form data.

It's a kinda-not-too-retarded idea, executed with maximum retardation.

lol.  Hopefully his query for handling this was transaction-based.  I can imagine the data cleanup scenarios involved if the whole thing were to fail in the middle of all these postbacks and this was going directly into production tables rather than staging tables.

Just goes to show it's not the language that's retarded, just the retards developers hacks.  What in the world was s/he thinking?

OK, I'm defending this one.



This WTF is actually a workaround for a browser WTF in the fact that if
a POST to a server comes back with a 302, not all browsers will repost
the original variables back to the redirected URL, especially if the
redirect is to an SSL site.   This is where Session or a
domain cookie would come in handy.

Manni:

I totally know why the programmer did this (at least I think I know). If you have all the information entered into the form and then submit it, you'll immediately go to the submitting page. If it takes more than a second or two for that page to process, it's more user-friendly to have a page that says "Please wait while we access your account" or whatever. What you need to do is submit the form data to the "Please wait..." page, and then have THAT page submit it to the page that will read in the form data.

It's a kinda-not-too-retarded idea, executed with maximum retardation.

Actually, I think it's simpler than that. If it was a "please wait" page, then there'd be something else in the body of that page. As it stands, this page displays nothing, it just uses javascript to resubmit the data.

The reason this was done is probably to avoid the message that IE pops up by default when an http form redirects to an https form or vice-versa. If a redirect had been used, that message would pop up and the user would have to click yes to shift into https mode. With this, the form redirects to an https without that message.

Of course, they should have changed the original form to send it to the right place in the first place, but hey...

 

We have one of these.  We need to post user data to a third party,
who provides a redirect on their system, to the remainder of their
application.  As a result, there is no need for a UI on our
end.  Sadly, someone decided to implement a hidden form just like
this using Java, rather than simply programatically posting to the
third party.



For all you Java/VB/Perl/PHP/C/C++/C# bashers, WTFs know no language.

True.  Actually, the best solution would have been to send the
user over to the SSL side before even entering the data to begin
with.  Some sites insist on having you start the shopping cart
process unsecured, then go to secured mode to start paying for the
item, thinking that SSL is too expensive (yes, it does slow down your
website).



Given today's server hardware, I think that cost is negligible... plus you can mod IIS5 and IIS6 to have

(previous post continued)

.... gzip compression on to improve your throughput for those pesky dialup users.

Otto:

Manni:

I totally know why the programmer did this...

Actually, I think it's simpler than that. If it was a "please wait" page, then there'd be something else in the body of that page. As it stands, this page displays nothing, it just uses javascript to resubmit the data.

Good eye, I didn't even notice that there was nothing actually being displayed on the page. Something else I just thought of, the developer isn't HTMLEncoding the querystring data. Wouldn't this lead to loss of data if there are double-quotes in the values?

christoofar:

OK, I'm defending this one.



This WTF is actually a workaround for a browser WTF in the fact that if
a POST to a server comes back with a 302, not all browsers will repost
the original variables back to the redirected URL, especially if the
redirect is to an SSL site.   This is where Session or a
domain cookie would come in handy.

But it's a GET.  Both of them are GETs.  The original request is demonstratably a GET because data is being pulled from Request.QueryString and not Request.Form.  And the javascript-fired request is also a GET.

This is a good way to make sure all your customers have javascript turned on.

And yes, if any input has a double-quote in it, all subsequent data for that input is lost.

Mung Kee:

We have one of these.  We need to post user data to a third party,
who provides a redirect on their system, to the remainder of their
application.  As a result, there is no need for a UI on our
end.  Sadly, someone decided to implement a hidden form just like
this using Java, rather than simply programatically posting to the
third party.



For all you Java/VB/Perl/PHP/C/C++/C# bashers, WTFs know no language.

Perhaps you could help me out then, as I am afraid I am about to commit a WTF for similar reasons.



We're using a third party to process credit card payments for us. 
After we get the info we need from the user, we're to redirect them
over to this third party's site using a POST.  However, since all
of our web pages are ASP.NET and as near as I can tell you can't POST
to a third party's website from an ASP.NET page, I'm a little curious
about what I should do (in case this seems familiar, I've already made
a post about this at
http://www.thedailywtf.com/forums/38891/ShowPost.aspx).



I've looked around about the issue, and just about every workaround I
have found involves something like today's WTF: creating a simple HTML
page containing hidden input fields for each piece of data that needs
to go over to the other site and then submitting that form, either via
javascript or the user.  In fact, if I'm not completely mistaken
(and I'm completely willing to admit it if I am), I think Alex even
suggested I do something similar in his response to the post I
parenthetically mentioned above.



If doing this is indeed as big a WTF as it seems, it'd be nice to find
out now, before it shows up on this site some day.  :)

Maurits:

christoofar:

OK, I'm defending this one.



This WTF is actually a workaround for a browser WTF in the fact that if
a POST to a server comes back with a 302, not all browsers will repost
the original variables back to the redirected URL, especially if the
redirect is to an SSL site.   This is where Session or a
domain cookie would come in handy.

But
it's a GET.  Both of them are GETs.  The original request is
demonstratably a GET because data is being pulled from
Request.QueryString and not Request.Form.  And the
javascript-fired request is also a GET.

Geez...I just noticed that.  So maybe my question and today's WTF
aren't as similar as I first thought.  Ten thousand apologies.

Alex Papadimoulis:

Yesterday, I learned an interesting
lesson: PHP programmers are rrrreaaaallly sensitive. Honestly, be
careful when suggesting that PHP (...), is overwhelmingly popular amongst hobbyist programmers.

Why be careful about it?

Stupid statement. It's like saying: "Honestly, be careful when
suggesting that Honda (Toyota, etc...) is overwhelmingly popular
amongst ... er anyone.

Stuff like this only happened in the Microsoft world because ASP and VBScript were so similar to PHP...

UncleMidriff:

Maurits:

christoofar:

OK, I'm defending this one.

This WTF is actually a workaround for a browser WTF in the fact that if a POST to a server comes back with a 302, not all browsers will repost the original variables back to the redirected URL, especially if the redirect is to an SSL site.   This is where Session or a domain cookie would come in handy.

But it's a GET.  Both of them are GETs.  The original request is demonstratably a GET because data is being pulled from Request.QueryString and not Request.Form.  And the javascript-fired request is also a GET.

Geez...I just noticed that.  So maybe my question and today's WTF aren't as similar as I first thought.  Ten thousand apologies.

Don't forget the tell-tale:
<form method="get" action="<%=fullUrl%>">

You could still have QueryString variables on POST action.  All you'd need to do is have action be something like 'page.aspx?var=value'.  Then, you'd get a lovely mix.

Alex Papadimoulis:

Dim fullUrl : fullUrl = _

"https://" & _

Request.ServerVariables("SERVER_NAME") & _

Request.ServerVariables("URL")

Pardon the ignorance of Request.ServerVariables but, doesn't this
result in a URL that will submit the form back to the current
page?  What's to stop it from continually doing it?  And why
use SSL if you're just going to use the GET method anyway?

UncleMidriff:

Mung Kee:

We have one of these.  We need to post user data to a third party,
who provides a redirect on their system, to the remainder of their
application.  As a result, there is no need for a UI on our
end.  Sadly, someone decided to implement a hidden form just like
this using Java, rather than simply programatically posting to the
third party.



For all you Java/VB/Perl/PHP/C/C++/C# bashers, WTFs know no language.

Perhaps you could help me out then, as I am afraid I am about to commit a WTF for similar reasons.



We're using a third party to process credit card payments for us. 
After we get the info we need from the user, we're to redirect them
over to this third party's site using a POST.  However, since all
of our web pages are ASP.NET and as near as I can tell you can't POST
to a third party's website from an ASP.NET page, I'm a little curious
about what I should do (in case this seems familiar, I've already made
a post about this at
http://www.thedailywtf.com/forums/38891/ShowPost.aspx).



I've looked around about the issue, and just about every workaround I
have found involves something like today's WTF: creating a simple HTML
page containing hidden input fields for each piece of data that needs
to go over to the other site and then submitting that form, either via
javascript or the user.  In fact, if I'm not completely mistaken
(and I'm completely willing to admit it if I am), I think Alex even
suggested I do something similar in his response to the post I
parenthetically mentioned above.



If doing this is indeed as big a WTF as it seems, it'd be nice to find
out now, before it shows up on this site some day.  :)

Honestly dude, you'll have to RTM on this one.  I worked with
classic ASP and COM at least 5 years ago, and probably implemented
something very much like this at some point.  I just don't know
the tools available to you these days.

Mung Kee:

Honestly dude, you'll have to RTM on this one.  I worked with
classic ASP and COM at least 5 years ago, and probably implemented
something very much like this at some point.  I just don't know
the tools available to you these days.

(Sorry, I guess that wasn't very helpful)


If ASP.NET has some networking libraries these days, you may be able to
open a connection to the remote URL and submit the data. 
Otherwise, you'll have to use another language from within your ASP to
do it.  That's the drawback of scripting.  You can't do
everything with it and sometimes it forces hacks like this.

UncleMidriff:

Mung Kee:

We have one of these.  We need to post user data to a third party, who provides a redirect on their system, to the remainder of their application.  As a result, there is no need for a UI on our end.  Sadly, someone decided to implement a hidden form just like this using Java, rather than simply programatically posting to the third party.

For all you Java/VB/Perl/PHP/C/C++/C# bashers, WTFs know no language.

Perhaps you could help me out then, as I am afraid I am about to commit a WTF for similar reasons.

We're using a third party to process credit card payments for us.  After we get the info we need from the user, we're to redirect them over to this third party's site using a POST.  However, since all of our web pages are ASP.NET and as near as I can tell you can't POST to a third party's website from an ASP.NET page, I'm a little curious about what I should do (in case this seems familiar, I've already made a post about this at http://www.thedailywtf.com/forums/38891/ShowPost.aspx).

I've looked around about the issue, and just about every workaround I have found involves something like today's WTF: creating a simple HTML page containing hidden input fields for each piece of data that needs to go over to the other site and then submitting that form, either via javascript or the user.  In fact, if I'm not completely mistaken (and I'm completely willing to admit it if I am), I think Alex even suggested I do something similar in his response to the post I parenthetically mentioned above.

If doing this is indeed as big a WTF as it seems, it'd be nice to find out now, before it shows up on this site some day.  :)

You can use the HttpWebRequest object in the .net framework library to pass in POST data to any URL and get a response stream back. 

Mung Kee:

Mung Kee:

Honestly dude, you'll have to RTM on this one.  I worked with classic ASP and COM at least 5 years ago, and probably implemented something very much like this at some point.  I just don't know the tools available to you these days.

(Sorry, I guess that wasn't very helpful)
If ASP.NET has some networking libraries these days, you may be able to open a connection to the remote URL and submit the data.  Otherwise, you'll have to use another language from within your ASP to do it.  That's the drawback of scripting.  You can't do everything with it and sometimes it forces hacks like this.

ASP.NET doesn't use scripting languages.  The entire .NET framework library and any language available to it (strongly typed and fully compiled) is at your disposal.

Alex Papadimoulis:

Don't even think of suggesting that
using a scalable, vendor-supported, compiled, type-safe platform, such
as ASP.NET or J2EE, is the only way to go for real web applications.

Erm... this is not quite what I would call a suggestion...

anyway, ymmv

Jeff S:

[quote userYou can use the HttpWebRequest object in the .net framework library to pass in POST data to any URL and get a response stream back. 

It really, really depends on how he needs to deal with this external page. If he actually has to redirect the client browser to their page, this might not work. Then again, it might work fine if he just needs to submit the data to their page and they're just going to redirect the browser back to his stuff anyway.

Without more info, it's difficult to know the "correct" way to do it.

 

Otto:

Jeff S:

[quote userYou can use the HttpWebRequest object in the .net framework library to pass in POST data to any URL and get a response stream back. 

It really, really depends on how he needs to deal with this external page. If he actually has to redirect the client browser to their page, this might not work. Then again, it might work fine if he just needs to submit the data to their page and they're just going to redirect the browser back to his stuff anyway.

Without more info, it's difficult to know the "correct" way to do it.

 

Absolutely.  It depends on your needs.  If your goal is to eventually redirect the client's browser, then doing it by generating a hidden HTML form and doing a quick javascript Submit() call is probably the easiest way to go.

Jeff S:

You can use the HttpWebRequest object in the .net framework library
to pass in POST data to any URL and get a response stream back.

Or in his case, HttpsWebRequest (credit card info). 

Jeff S:

Mung Kee:

Mung Kee:

Honestly
dude, you'll have to RTM on this one.  I worked with classic ASP
and COM at least 5 years ago, and probably implemented something very
much like this at some point.  I just don't know the tools
available to you these days.

(Sorry, I guess that wasn't very helpful)
If
ASP.NET has some networking libraries these days, you may be able to
open a connection to the remote URL and submit the data. 
Otherwise, you'll have to use another language from within your ASP to
do it.  That's the drawback of scripting.  You can't do
everything with it and sometimes it forces hacks like this.

ASP.NET doesn't use scripting languages.  The entire .NET
framework library and any language available to it (strongly typed and
fully compiled) is at your disposal.

Thanks.  Ignorance admitted and point taken.

Jeff S:

Otto:

Jeff S:

[quote userYou can use the HttpWebRequest object in the .net
framework library to pass in POST data to any URL and get a response
stream back. 

It really, really depends on how he needs to deal with this external
page. If he actually has to redirect the client browser to their page,
this might not work. Then again, it might work fine if he just needs to
submit the data to their page and they're just going to redirect the
browser back to his stuff anyway.

Without more info, it's difficult to know the "correct" way to do it.

 

Absolutely.  It depends on your needs.  If your goal
is to eventually redirect the client's browser, then doing it by
generating a hidden HTML form and doing a quick javascript
Submit() call is probably the easiest way to go.

Right, sorry, I should have made that clear in my intitial post.



I've used the HttpWebRequest object in another project to do behind the
scenes type things, but in this credit card situation, I need to
redirect the user's browser to the third party page.

UncleMidriff:

Jeff S:

Otto:

Jeff S:

[quote userYou can use the HttpWebRequest object in the .net
framework library to pass in POST data to any URL and get a response
stream back. 

It really, really depends on how he needs to deal with this external
page. If he actually has to redirect the client browser to their page,
this might not work. Then again, it might work fine if he just needs to
submit the data to their page and they're just going to redirect the
browser back to his stuff anyway.

Without more info, it's difficult to know the "correct" way to do it.

 

Absolutely.  It depends on your needs.  If your goal
is to eventually redirect the client's browser, then doing it by
generating a hidden HTML form and doing a quick javascript
Submit() call is probably the easiest way to go.

Right, sorry, I should have made that clear in my intitial post.



I've used the HttpWebRequest object in another project to do behind the
scenes type things, but in this credit card situation, I need to
redirect the user's browser to the third party page.

In the solution I suggested (opening a connection to the 3rd party and
submitting), you wouldn't be redirecting exactly.  You would
essentially be piping the initial request to the 3rd party to the
user.  Once they see that content, they will be in the 3rd party's
application.  I'm not sure if this is the same way
Http{s}WebRequest works. 



Note: If you choose to do it this way, be sure that the 3rd party uses
absolute URLs on that first page, because they will be prefixed by your
domain of they use relative, since it's piped through your server.

Mung Kee:

Pardon the ignorance of Request.ServerVariables but, doesn't this result in a URL that will submit the form back to the current page?  What's to stop it from continually doing it?  And why use SSL if you're just going to use the GET method anyway?

I'm not defending the method used, but I wanted to point out that the querystring is not passed in plaintext over an SSL connection.  The transaction goes something like this:

1. Client resolves domain name to an IP address.
   
2. Client connects to server, using IP address.
   
3. Server returns public key from SSL certificate.
   
4. Client and server negotiate a session key.
   
5. Client sends request over connection encrypted via session key.
   
6. Server returns encrypted response.

The client doesn't send the querystring, the script name, or even the domain name in plaintext.  BTW, that's why you can't effectively use host headers with SSL.

 

Mung Kee:

We have one of these.  We need to post user data to a third party,
who provides a redirect on their system, to the remainder of their
application.  As a result, there is no need for a UI on our
end.  Sadly, someone decided to implement a hidden form just like
this using Java, rather than simply programatically posting to the
third party.



For all you Java/VB/Perl/PHP/C/C++/C# bashers, WTFs know no language.

Not true at all.  WTFs know every language, catch every language
with its pants down, and collect blackmail evidence (for the bashers
among others).



Sincerely,



Gene Wirchenko

Probably ought to explain further, the entire
point of this page was to redirect to an https version. There's a
missing line at the top that basically tested
Request.ServerVariables("URL") to see whether it started with https and
ran this code if it didn't (otherwise it returned the correct page)



And Response.Redirect would have done the job just fine!

Jeff S:

Mung Kee:

Mung Kee:

Honestly
dude, you'll have to RTM on this one.  I worked with classic ASP
and COM at least 5 years ago, and probably implemented something very
much like this at some point.  I just don't know the tools
available to you these days.

(Sorry, I guess that wasn't very helpful)
If
ASP.NET has some networking libraries these days, you may be able to
open a connection to the remote URL and submit the data. 
Otherwise, you'll have to use another language from within your ASP to
do it.  That's the drawback of scripting.  You can't do
everything with it and sometimes it forces hacks like this.

ASP.NET doesn't use scripting languages.  The entire .NET
framework library and any language available to it (strongly typed and
fully compiled) is at your disposal.

You don't mean that one could write ASP.Net using IronPython now do you?

Gene Wirchenko:

Mung Kee:

We have one of these.  We need to post user data to a third party,
who provides a redirect on their system, to the remainder of their
application.  As a result, there is no need for a UI on our
end.  Sadly, someone decided to implement a hidden form just like
this using Java, rather than simply programatically posting to the
third party.



For all you Java/VB/Perl/PHP/C/C++/C# bashers, WTFs know no language.

Not true at all.  WTFs know every language, catch every language
with its pants down, and collect blackmail evidence (for the bashers
among others).



Sincerely,



Gene Wirchenko

WTFs know no language, meaning they're pervasive.  I know it's a leap but that's my feeble attempt at philosophy. 

bobintetley:

Probably ought to explain further, the entire point of this page was to redirect to an https version. There's a missing line at the top that basically tested Request.ServerVariables("URL") to see whether it started with https and ran this code if it didn't (otherwise it returned the correct page)

And Response.Redirect would have done the job just fine!

Given that he's using GET, Reponse.Redirect(fullUrl) would have indeed worked just fine.

If he was using POST, then there are cases where it would not work.

masklinn:

Jeff S:

Mung Kee:

Mung Kee:

Honestly dude, you'll have to RTM on this one.  I worked with classic ASP and COM at least 5 years ago, and probably implemented something very much like this at some point.  I just don't know the tools available to you these days.

(Sorry, I guess that wasn't very helpful)
If ASP.NET has some networking libraries these days, you may be able to open a connection to the remote URL and submit the data.  Otherwise, you'll have to use another language from within your ASP to do it.  That's the drawback of scripting.  You can't do everything with it and sometimes it forces hacks like this.

ASP.NET doesn't use scripting languages.  The entire .NET framework library and any language available to it (strongly typed and fully compiled) is at your disposal.

You don't mean that one could write ASP.Net using IronPython now do you?

If it's a .NET language, then you can use it with ASP.NET.

Ugh. Typo. I meant:

Response.Redirect(fullURL & Request.QueryString(qsItm))

 

Get a real payment gateway that provides an API to their services, I
use authorize.net and it is the one I prefer, but I have also used
PayPal's Web Payments Pro (even they provide a logical way to interfece
with them).



Basically, you set up a SOAP request with a username and password,
credit card details, etc, and (at least on linux) use curl to send the
data and receive a response... and use a cert to encrypt the line.



Even if they don't allow for this, you can use curl to submit the data
to the server from the server behind the scenes (rather than relying on
javascript, which the client may not have enabled). I am sure that
something like curl exists on .NET platforms, although I have never
done .NET work.



If you are cheap or too stupid to use either method, you could just use
hidden input fields and submit the form to the payment gateway for
processing (basically show them their order total and have the details
they entered in hidden inputs) and submit to the site, and have a page
that captures the post back.



Either way, I don't see the reason for the suggestions of silliness
with javascript you "experts" have made. :D    

Jeff S:

masklinn:

Jeff S:

Mung Kee:

Mung Kee:

Honestly dude, you'll have to RTM on this one.  I worked with classic ASP and COM at least 5 years ago, and probably implemented something very much like this at some point.  I just don't know the tools available to you these days.

(Sorry, I guess that wasn't very helpful)
If ASP.NET has some networking libraries these days, you may be able to open a connection to the remote URL and submit the data.  Otherwise, you'll have to use another language from within your ASP to do it.  That's the drawback of scripting.  You can't do everything with it and sometimes it forces hacks like this.

ASP.NET doesn't use scripting languages.  The entire .NET framework library and any language available to it (strongly typed and fully compiled) is at your disposal.

You don't mean that one could write ASP.Net using IronPython now do you?

If it's a .NET language, then you can use it with ASP.NET.

True its a .Net language, but you cannot yet use it with ASP.Net. IronPython is not quite capable of generating assemblies consumable by ASP.Net (the whole lack of a compiler to create an assembly up front thing).  I believe this is a goal for the 1.0 release though.  Might be post 1.0, though...

Alex Papadimoulis:

Don't even think
of suggesting that using a scalable, vendor-supported, compiled,
type-safe platform, such as ASP.NET or J2EE, is the only way to go for
real web applications. You'll really hear it then. Heck, I'll even get
some flak for suggesting not to suggest it.

Hell yes. Write in Haskell. The only real web application language. Especially for hobbyists.



(Though I'm in favor of Common Lisp. Perfectly allowed by my 6€/month web host. :) )

Jeff S:

Mung Kee:

Mung Kee:

Honestly dude, you'll have to RTM on this one.  I worked with classic ASP and COM at least 5 years ago, and probably implemented something very much like this at some point.  I just don't know the tools available to you these days.

(Sorry, I guess that wasn't very helpful)
If ASP.NET has some networking libraries these days, you may be able to open a connection to the remote URL and submit the data.  Otherwise, you'll have to use another language from within your ASP to do it.  That's the drawback of scripting.  You can't do everything with it and sometimes it forces hacks like this.

ASP.NET doesn't use scripting languages.  The entire .NET framework library and any language available to it (strongly typed and fully compiled) is at your disposal.

Uhm, according to the MSDN help files, JScript.NET *is* a scripting language, and you can definitely use it to create ASP.NET applications. From the MSDN Help File:

"JScript .NET is a modern scripting language with a wide variety of applications. It is a true object-oriented language, and yet it still keeps its "scripting" feel. JScript .NET maintains full backwards compatibility with previous versions of JScript, while incorporating great new features and providing access to the common language runtime and .NET Framework."

christoofar:

True.  Actually, the best solution would have been to send the
user over to the SSL side before even entering the data to begin
with.  Some sites insist on having you start the shopping cart
process unsecured, then go to secured mode to start paying for the
item, thinking that SSL is too expensive (yes, it does slow down your
website).





Given today's server hardware, I think that cost is negligible... plus you can mod IIS5 and IIS6 to have

From my understanding the server must generates the secure primes used
by RSA which is the most costly part of the transaction process. It was
thought that servers are big powerful machines and clients were small
insignificant computers, if we were to redesign we would have the
client compute these primes (they can be verified as being secure
cheaply). I remember amazon hardware accelerated this process for that
very reason. So no, the cost is not negligible and no gzip compression
is not really the answer. But I may be wrong.





I agree with your original point however. I would think you would want
the shopping chart to be secure anyway? E.g. for legal reasons.

Anonymous:

Mung Kee:

Pardon the
ignorance of Request.ServerVariables but, doesn't this result in a URL
that will submit the form back to the current page?  What's to
stop it from continually doing it?  And why use SSL if you're just
going to use the GET method anyway?

I'm not defending the method used, but I wanted to point out that the querystring is not passed in plaintext over an SSL connection.  The transaction goes something like this:

1. Client resolves domain name to an IP address.
   
2. Client connects to server, using IP address.
   
3. Server returns public key from SSL certificate.
   
4. Client and server negotiate a session key.
   
5. Client sends request over connection encrypted via session key.
   
6. Server returns encrypted response.

The client doesn't send the querystring, the script name, or even
the domain name in plaintext.  BTW, that's why you can't
effectively use host headers with SSL.

Whoa whoa... this is news to me.  I misinformed someone about this recently.

Mung Kee:

Alex Papadimoulis:

Dim fullUrl : fullUrl = _

"https://" & _

Request.ServerVariables("SERVER_NAME") & _

Request.ServerVariables("URL")

Pardon the ignorance of Request.ServerVariables but, doesn't this
result in a URL that will submit the form back to the current
page?  What's to stop it from continually doing it?  And why
use SSL if you're just going to use the GET method anyway?

I think the point is that it's replacing http:// with https://.

Jeff S:

ASP.NET doesn't use scripting languages.  The entire .NET framework library and any language available to it (strongly typed and fully compiled) is at your disposal.

Well, anything that is meant to be executed client-side must be in a scripting language. Just because the server uses .NET, that does not mean every browser does.

So yes, you do use scripting languages in .NET web applications.

seizethedave:

Anonymous:

Mung Kee:

Pardon the ignorance of Request.ServerVariables but, doesn't this result in a URL that will submit the form back to the current page?  What's to stop it from continually doing it?  And why use SSL if you're just going to use the GET method anyway?

I'm not defending the method used, but I wanted to point out that the querystring is not passed in plaintext over an SSL connection.  The transaction goes something like this:

1. Client resolves domain name to an IP address.
   
2. Client connects to server, using IP address.
   
3. Server returns public key from SSL certificate.
   
4. Client and server negotiate a session key.
   
5. Client sends request over connection encrypted via session key.
   
6. Server returns encrypted response.

The client doesn't send the querystring, the script name, or even the domain name in plaintext.  BTW, that's why you can't effectively use host headers with SSL.

Whoa whoa... this is news to me.  I misinformed someone about this recently.

Don't rush to spread the news. The querystring is never encrypted.

MartinL:

seizethedave:

Anonymous:

Mung Kee:

Pardon the ignorance of
Request.ServerVariables but, doesn't this result in a URL that will
submit the form back to the current page?  What's to stop it from
continually doing it?  And why use SSL if you're just going to use
the GET method anyway?

I'm not defending the method used, but I wanted to point out that the querystring is not passed in plaintext over an SSL connection.  The transaction goes something like this:

1. Client resolves domain name to an IP address.
   
2. Client connects to server, using IP address.
   
3. Server returns public key from SSL certificate.
   
4. Client and server negotiate a session key.
   
5. Client sends request over connection encrypted via session key.
   
6. Server returns encrypted response.

The client doesn't send the querystring, the script name, or even
the domain name in plaintext.  BTW, that's why you can't
effectively use host headers with SSL.

Whoa whoa... this is news to me.  I misinformed someone about this recently.

Don't rush to spread the news. The querystring is never encrypted.

Sorry, but you're wrong Martin:



From http://www.ietf.org/rfc/rfc2818.txt [HTTP Over TLS]

2.1.  Connection Initiation

   The agent acting as the HTTP client should also act as the TLS
   client.  It should initiate a connection to the server on the
   appropriate port and then send the TLS ClientHello to begin the TLS
   handshake. When the TLS handshake has finished. The client may then
   initiate the first HTTP request.  All HTTP data MUST be sent as TLS
   "application data".  Normal HTTP behavior, including retained
   connections should be followed.

This means that the SSL-encryption _must_ be established before the
client sends the request data - and the query string is part of the
request data, so it is sent over the secure line.



regards



fg

you realize this wtf would probably never have happened if this had been written in php...

(i was getting all ready to defend php, until i remembered that i am a hobby programmer, having left those painful days of being a pro behind many years ago.)

It's true that when using a secure (https) connection, that the URL is encrpted while passing over the connection from client to server. However it's still not a good idea to have sensitive data in the query string, because of how the user agent and server handle URLs:

The user agent will:

• Display the URL in the address bar, meaning that, for example, a password might be visible in plain view.
  
• Store the URL in the address history - the rules about not storing data from secure pages does not apply to the URL for the page.

Also, the server may log the URL of the request, meaning that the sensitive data could be visible in the server logs.

Phil D

MartinL:

Jeff S:

ASP.NET doesn't use scripting languages.  The entire .NET
framework library and any language available to it (strongly typed and
fully compiled) is at your disposal.

Well, anything that is meant to be executed client-side must be in a
scripting language. Just because the server uses .NET, that does
not mean every browser does.

So yes, you do use scripting languages in .NET web applications.

No offense, but I would hope that everyone here participating in this
forum would understand that the client-side web browsers don't "use"
.NET. 

MartinL:

Jeff S:

ASP.NET doesn't use scripting languages.  The entire .NET
framework library and any language available to it (strongly typed and
fully compiled) is at your disposal.

Well, anything that is meant to be executed client-side must be in a
scripting language. Just because the server uses .NET, that does
not mean every browser does.

So yes, you do use scripting languages in .NET web applications.

Anything executed client-side has very little to do with .NET.

Mung Kee:

MartinL:

Jeff S:

ASP.NET doesn't use scripting languages.  The entire .NET
framework library and any language available to it (strongly typed and
fully compiled) is at your disposal.

Well, anything that is meant to be executed client-side must be in a
scripting language. Just because the server uses .NET, that does
not mean every browser does.

So yes, you do use scripting languages in .NET web applications.

Anything executed client-side has very little to do with .NET.

...and what about ActiveX and Applets?  Scripting?