The Daily WTF: Curious Perversions in Information Technology

Manni · 2005-09-15 Reply Admin

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.

AtomicTesting · 2005-09-15 Reply Admin

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.

bugsRus · 2005-09-15 Reply Admin

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?

christoofar · 2005-09-15 Reply Admin

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.

Otto · 2005-09-15 Reply Admin

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...

Mung Kee · 2005-09-15 Reply Admin

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.

christoofar · 2005-09-15 Reply Admin

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

christoofar · 2005-09-15 Reply Admin

(previous post continued)
.... gzip compression on to improve your throughput for those pesky dialup users.

Manni · 2005-09-15 Reply Admin

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?

Maurits · 2005-09-15 Reply Admin

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.

UncleMidriff · 2005-09-15 Reply Admin

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. :)

UncleMidriff · 2005-09-15 Reply Admin

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.

2005-09-15 Reply Admin

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.

fregas · 2005-09-15 Reply Admin

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

2005-09-15 Reply Admin

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.

Mung Kee · 2005-09-15 Reply Admin

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?

Mung Kee · 2005-09-15 Reply Admin

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 · 2005-09-15 Reply Admin

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.

Jeff S · 2005-09-15 Reply Admin

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.

Jeff S · 2005-09-15 Reply Admin

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.

2005-09-15 Reply Admin

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

Otto · 2005-09-15 Reply Admin

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.

Jeff S · 2005-09-15 Reply Admin

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.

Mung Kee · 2005-09-15 Reply Admin

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).

Mung Kee · 2005-09-15 Reply Admin

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.

UncleMidriff · 2005-09-15 Reply Admin

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.

Mung Kee · 2005-09-15 Reply Admin

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.

2005-09-15 Reply Admin

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:

Client resolves domain name to an IP address.
Client connects to server, using IP address.
Server returns public key from SSL certificate.
Client and server negotiate a session key.
Client sends request over connection encrypted via session key.
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.

Gene Wirchenko · 2005-09-15 Reply Admin

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

bobintetley · 2005-09-15 Reply Admin

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!

masklinn · 2005-09-15 Reply Admin

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?

Mung Kee · 2005-09-15 Reply Admin

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.

Otto · 2005-09-15 Reply Admin

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.

Jeff S · 2005-09-15 Reply Admin

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.

Otto · 2005-09-15 Reply Admin

Ugh. Typo. I meant:

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

2005-09-15 Reply Admin

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

2005-09-15 Reply Admin

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...

2005-09-15 Reply Admin

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. :) )

jeremydwill · 2005-09-15 Reply Admin

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."

2005-09-15 Reply Admin

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.

seizethedave · 2005-09-15 Reply Admin

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:

Client resolves domain name to an IP address.
Client connects to server, using IP address.
Server returns public key from SSL certificate.
Client and server negotiate a session key.
Client sends request over connection encrypted via session key.
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.

2005-09-16 Reply Admin

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://.

MartinL · 2005-09-16 Reply Admin

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.

MartinL · 2005-09-16 Reply Admin

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:

Client resolves domain name to an IP address.
Client connects to server, using IP address.
Server returns public key from SSL certificate.
Client and server negotiate a session key.
Client sends request over connection encrypted via session key.
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.

2005-09-16 Reply Admin

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:

Client resolves domain name to an IP address.
Client connects to server, using IP address.
Server returns public key from SSL certificate.
Client and server negotiate a session key.
Client sends request over connection encrypted via session key.
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

III · 2005-09-16 Reply Admin

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.)

2005-09-16 Reply Admin

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

Jeff S · 2005-09-16 Reply Admin

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.

Mung Kee · 2005-09-16 Reply Admin

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 · 2005-09-16 Reply Admin

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?

Directing a Redirect

Leave a comment on “Directing a Redirect”