- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
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.
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.
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?
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.
Admin
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...
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.
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
Admin
(previous post continued)
.... gzip compression on to improve your throughput for those pesky dialup users.
Admin
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?
Admin
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.
Admin
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. :)
Admin
Geez...I just noticed that. So maybe my question and today's WTF aren't as similar as I first thought. Ten thousand apologies.
Admin
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.
Admin
Stuff like this only happened in the Microsoft world because ASP and VBScript were so similar to PHP...
Admin
Don't forget the tell-tale:
<form method="get" action="<%=fullUrl%>">
<FONT color=#000000>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.</FONT>
Admin
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?
Admin
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.
Admin
(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.
Admin
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. <FONT size=1><FONT size=1>
</FONT></FONT>Admin
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.
Admin
Erm... this is not quite what I would call a suggestion...
anyway, ymmv
Admin
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.
Admin
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.
Admin
Or in his case, HttpsWebRequest (credit card info).
Admin
Thanks. Ignorance admitted and point taken.
Admin
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.
Admin
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.
Admin
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:
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.
Admin
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
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!
Admin
You don't mean that one could write ASP.Net using IronPython now do you?
Admin
WTFs know no language, meaning they're pervasive. I know it's a leap but that's my feeble attempt at philosophy.
Admin
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.
Admin
If it's a .NET language, then you can use it with ASP.NET.
Admin
Ugh. Typo. I meant:
Response.Redirect(fullURL & <FONT color=#000000>Request.QueryString(qsItm))</FONT>
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
Admin
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...
Admin
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. :) )
Admin
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."
Admin
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.
Admin
Whoa whoa... this is news to me. I misinformed someone about this recently.
Admin
I think the point is that it's replacing http:// with https://.
Admin
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.
Admin
Don't rush to spread the news. The querystring is never encrypted.
Admin
Sorry, but you're wrong Martin:
From http://www.ietf.org/rfc/rfc2818.txt [HTTP Over TLS]
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
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.)
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:
Also, the server may log the URL of the request, meaning that the sensitive data could be visible in the server logs.
Phil D
Admin
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.
Admin
Anything executed client-side has very little to do with .NET.
Admin
...and what about ActiveX and Applets? Scripting?