- 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
This is a large WTF I'm surprised nobody has commented on.
Properly formatted data is not the same as valid data. Having somebody else's SSN against your record could be much much worse than having a fake SSN.
I've lost count of the number of braindead GUIs or web forms that have rejected my slightly unexpected input as invalid.
I recently encountered a process that rejected anything involving a State that the company did not service as being "Invalid XML". Yeah, they built the list of States they service into their DTD. Instead of returning an error for that element later, it would drop the whole file.
Admin
<FONT face=Tahoma size=2>If you used parmeterized queries, then </FONT><FONT color=#ff0000><FONT face=Tahoma size=2>'; DROP DATABASE;</FONT> </FONT><FONT face=Tahoma color=#000000 size=2>would be converted to a literal string, assuming you specified it as a varchar. If you specified it as some other, non-text, type, then your code would crash and the query would not be run. If you could actually see the resulting SQL, it would look something like:</FONT>
<FONT face=Tahoma color=#000000 size=2>myField = '''; DROP DATABASE;'</FONT>
<FONT face=Tahoma size=2>This would just get inserted as a regular string. The moral of the story, is to use query parameters if the environment you're working in makes them available to you. Otherwise, write your own functions to escape all necessary characters and validate that they have an appropriate value based on the column type.</FONT>
Admin
See the discussion. Note that they're not real anonymous functions. Note also the solution suggested; concatenating a function together and using eval! Obviously! What else? It's like lisp marcos designed by a schizophrenic person!
Again, the PHP developers have taken a good idea and completely missed the point.
Admin
It sounds like you're fairly well set on using ColdFusion and nothing but ColdFusion. Heck, if the tool works, keep it in the toolbox.
The thing about enterprise systems is that they have to play well with other enterprise systems, and be understood by future programmers. That said, the popularity of the language is a real issue. Mainstream languages tend to offer an enterprise some assurance that there is a ready supply of programmers that can slide into the driver's seat.
Not to mention the confidence it gives the marketing department when they can say "yes" to the Big Global Client Company, "our project can be easily understood by your programmers". It saves them from saying "Yes, it can be easily understood by your ColdFusion programmers".
Not to chide ColdFusion, or your enthusiasm about it...but you might consider it's popularity before you try to sell it too far up the ladder.
Admin
Now, you see, MSIE doesn't actually have a proper XHTML parser. It has an XML parser and it has an HTML parser, but the XML parser doesn't recognise the XHTML namespace, so you won't see any XHTML output by passing it as XML -- go ahead, try it (all the default CSS rules that apply for HTML are ignored, making it nearly impossible to get anything like HTML even if you write your own stylesheet to define all the default values).
MSIE does, however, have a rather excellent tagsoup parser. What is tagsoup? Tagsoup is the charming nickname HTML authors apply to everything that is not standard HTML or XHTML (or standard XML), but kinda looks like it. The most obvious places for examples of tagsoup are GeoCities and every major website, because most web authors don't understand or care about web standards in the first place.
Tagsoup is an attempt at HTML that is not standards compliant, i.e. it does not follow the rules of the doctype it uses, if any, and it's quite possibly not even well-formed.
Now, the problem with MSIE is that its tagsoup parser is so useful, that nobody bothered creating a standards compliant parser for it. The differences become obvious once you start toying around with CSS and compare the results of other browsers -- and I'm not talking about problems caused by the CSS specs not being specific enough about the implementation.
In fact, the HTML tagsoup parser is good enough to interprete even the most mangled HTML. This is where XHTML parsing comes into play.
Yes, most browsers CAN parse XHTML if you send it to them and tell them it's HTML, but that doesn't mean they recognise it as such OR treat it as such. They will treat it as HTML tagsoup, unless they follow a non-recommended practice called "doctype sniffing", which isn't exactly on par with what the standards say to begin with.
That's kind of like saying you understand Dutch because you know German and can "recognise" all the words similar enough and just ignore those that you are not familiar with and fill in the gaps with what words you might expect to be there if it were a German text to begin with.
That it can parse it and output something remotely similar to what you expect doesn't mean it supports it.
MSIE does not understand XHTML. Many browsers do, MSIE does not. Lynx doesn't either, as far as I know, and it will probably take a while until XHTML becomes mainstream in terms of browser support. Until then we'll only have loads of websites sending out tagsoup because they falsely declare their XHTML as HTML (AFAIK even Mozilla treats those as "non-standard" HTML rather than XHTML -- this is what the web standards effectively tell you to do, anyway).
As for the MIME type -- go ahead and open a website using the XHTML mime type in MSIE. You will get a nice file download trigger. If you don't, the website is sending a different mime type (i.e. text/html) that MSIE supports rather than application/xhtml+xml.
Also note that as it is now, MSIE can simply not support that mime type. Without proper XHTML support the only two options would be parsing it as HTML (which is wrong, because HTML parsers don't understand XHTML as anything other than tagsoup) or parsing it as XML (which would be a legitimate fallback (as per the definition of the +xml mimetype suffix), but not what the user or web designer might have intended (as you will, essentially, see the prettified sourcecode rather than a flashy web app).
The main difference is that an XHTML parser has to make sure it's dealing with wellformed XML first. That is essential. It may not have any tagsoup support. A wellformedness error in XML means a parser error, which means a fatal error, i.e. termination of the parser. Open a non-wellformed XML file in any XML-capable browser (MSIE, Mozilla, etc -- just make sure it has the right mimetype/filetype assigned (i.e. application/xml or text/xml and .xml as filename suffix)) and you will see what even the slightest deviation from wellformed XML will result in.
Letting MSIE parse XHTML as HTML even if it is explicitly sent as XHTML (i.e. per mimetype) would be fatal to XHTML and, by extension, XML. XML is a lot stricter than HTML in terms of syntax. Ignoring the strict ruleset defeats the purpose of XML and the reformulation of HTML within the XML ruleset (i.e. XHTML).
The best current practice if you want to work with XHTML in a Real World environment of a web application is to convert the XHTML you generate to HTML in another step if the browser doesn't advertise its XHTML support explicitly. Leaving that additional layer out is fine, but then you're shutting out all non-XHTML browsers without providing a fallback (i.e. MSIE, which is still the most widespread browser). An alternative is working with multiple sets of templates, one for XHTML and one for HTML, which saves you the overhead of buffering the output before converting it, but introduces the overhead of having to maintain two very similar sets of templates (which will probably not make much sense until the advent of XHTML 2.0, which has very different elements and little similarity with the old HTML).
Another approach is only generating XML output and parsing that server-side with XSLT so you end up with an HTML or XHTML output. That only means you have to maintain the XSLT stylesheets, but introduces the overhead of having another proprietary XML dialect and requring XSL transformation as additional layer (if the XHTML output was created with the limitations of HTML in mind, e.g. no empty elements that require a closing tag in HTML (<li/> is fine, <script/> is not) you could have a very simple, but error-prone, transformation algorithm which works with one or two simple search-and-replaces -- replacing xml:lang (preferred in XHTML) and the like with lang (preferred in HTML, but deprecated in XHTML 1.1) and removing the trailing slashes from empty elements, plus a slight manipulation of the header to change the doctype and remove the namespace).
Most web designers have the same idea of HTML that was common in the 1990s, but want to use "XHTML" because it's more buzzword compliant. The result is usually HTML tagsoup that kinda looks like XHTML if you close both eyes and imagine an elephant. Same tale as for the use of stylesheets, really. It's all too common to see inline styles in production environments (intended for tweaks and discouraged for recurring cases) or having table layouts with font tags all over it prettified with a few classes. Not to mention how many effects tend to be created with crufty JavaScript fragments where one or two lines of CSS could provide the same effect without relying on proper JavaScript support -- and let's not forget the proprietary CSS additions introduced by MS, Netscape and, intended for XUL and testing only, Mozilla.
CAPTCHA: awesomeness -- petition to add "hawtsomeness"
Admin
And seven pages later they're STILL debating CF vs PHP et al..... .SHEEEESH! Don't you people have girlfriends?
And besides, everyone knows the only truly powerful web development language is ASMIL
Admin
<font size="6"> END OF COLDFUSION FLAMEWAR</font>
Any posting mentioning ColdFusion below this line will be mercilessly deleted. Please start a new thread in "General Discussions" if you want to go on with that topic.
Admin
While I see the point you're trying to make, if I were your boss and saw x = x++ + 3; instead of x += 4;, I would seriously reconsider whether you're qualified to be working for me as a programmer.
Admin
And Pacific Islanders (a lot of Polynesian languages use an apostrophe to represent a glottal stop. Hawaii as a well-known instance is of course really Hawai'i).
Oh, and you don't have to ban the Irish if they're not using the anglicised versions of their names: In Irish that "O'" is a capital O with an acute accent on top.
Last last lasty thing: there's more to this escaping than just avoiding injection attacks: if you insert a string containing an apostrophe between single quotes in a dynamic SQL query, you'll get an error because you now have unbalanced single quotes (that's why your typical injection attack might have something like "' or 1 =1;--" if it's targetting SQL Server, for instance, because you want to comment out the final quote in that case). I came across a funny error a while ago in our timesheeting application, where someone had dutifully escaped single quotes in the the input...but unfortunately, they did this in strings that were actually parameter values for a stored procedure. So Mr O'Connell ended up on the database as O''Connell. Idiots.
Admin
Speaking of nice users escaping stuff - I know of a bank where they are entering the company or account holder's names when they do a search in uppercase putting % instead of spaces. So if they have to search for Jon Doe they would enter: %JON%DOE%... and this is a bank... they just cry for sql injection attacks...
Admin
mod's note: removed non-related quote
Typically, I eliminate puncuation marks during validation and ( UPPERCASE ) all names before inserting into a database. This makes for easy comparison and handles the caps-lock key issues.
O'Mally becomes OMALLY
D'Augustino becomes DAUGUSTINO
I generally keep two fields for each name. One as the original, the second as formatted. The formatted for comparison, the original for display.
How do you handle name validation?
Admin
I've made similar systems, but the second field contained a phonetic ("sounds-like") code of the name, for exented search possibilities.
Admin
I've never taken it that level. What is that... Soundex?
Admin
Of course that problem assumes another WTF, running the user code as an admin user because there is no possible way any user could ever execute arbitrary SQL on the database server.
Admin
I've made my own function, roughly similiar to soundex, but adapted to the German language, with extra consideration for Bohemian names; here in Austria, many people have names that originate from Boehmia; sometimes, they are transcribed to German notation, sometimes not. For example, the names "Svec" and "Schwätz" sound identically. I'm not a linguist, but that function works well.
Admin
I got an official SSN with the first three digits being 929 as an exchange student in 2003, valid for a single year.
Admin
Your article doesn't help at all. We all know we can keep some text files in source control systems. We all know we can script the database and as you say "It is relatively simple write a script to pull out a listing of all changes that have been made between any two committed versions." ... well if it's relatively simple why didn't you bother publishing such a script for MSSQL or MySQL for example? I took a couple of minutes to read your "article" and it sounds like an ad for SVN.
Another statement that bugged me: "Between subversion and CVS, SVN seemed to be the better system" ... well, would you bother explaining why? Right now it sounds like "it's better, trust me", well without any in-depth analysis I really can't take someones word for truth without the proper proofs.
Oh and this one : "In addition I had not heard of many negative experiences of people moving from CVS to SVN" just made me say "WTF, so you heard some... well, would you care sharing us what are the possible problems that you know about and how (if ever) they got solved"?
No offense, just pointing out the obvious...
Admin
Oh please, the web is full of comparison between CVS and SVN.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
Admin
Of course it's technically possible but the hardest part is to motivate your fellow programmers to do it. I'm working with companies that use Oracle, and it seems that most programmers writing PL/SQL stored procedures do that with TOAD directly from/into the database, without ever having source files on their hard disk. No versioning, conflicting changes etc... you name it.
Admin
There are plenty of articles on that one (including the design docs of subversion, since it's basic goal is to be "a better CVS).
The main advantages of SVN over CVS are:
As for negatives experiences of moving from CVS to SVN, never heard any myself beyond users having to reconfigure their muscle memories to the new CLI commands.
Admin
That should be part of the article, or at least a couple of links, that was my point.
Well said, initially I wanted to make this point, then read the article and got bugged by some statements and forgot where I started from. Unless you provide a tool to work with the database that will keep track of the changes, you will have to create scriptis of the entire database and later compare them to extract changes somehow (if ever possible)...
In any case the article is less worth next to nothing IMO without those notes and examples. In theory we all know we better keep scripts of all changes we do on the database, but unless the company introduces penalties for not doing it (and I didn't hear about any company doing this) - most people don't do it. I personally prefer reading create table scripts to understand the structure of a database rather than using a visual tool like toad or enterprise manager and diagrams are nice for less than 15 tables, more than that they just add to the confusion.
Admin
I'm sorry,but I'm still stuck here. Did he mean imperative? imperious? declarative? impertinent? imputative?
I don't see how any of those apply to a programming language.
Admin
Yes, it takes a lot of time and work to reengineer usefull ERDs out of a non-trivial database. Relatively good for this job is (at least in my experience) Aqua Data Studio (a generic database frontend written in Java) but maybe there are even better dedicated tools.
Admin
The word is of course imperative. Most common programming languages are imperative. The opposite are declarative programming lanuages, e.g. functional languages (Lisp, Haskell etc.) and logical languages (Prolog etc.)
Admin
Wow, that really amazes me. Where I work we have all of our stored procedures in a directory in our source repository, and every script has to be run by the DBA for us, even in Dev, before we can migrate it to any other environments (Test, QA, Prod). Actually, we can update our own sprocs in Dev, for testing purposes, but we still have to submit the final script to the DBA, and check it into source control, before we can move on. This is actually exactly what I was doing this afternoon.
(We had to fight over even that, which is a bit of a WTF in itself; originally, they didn't want us to be able to touch them at all in Dev, but that would mean the DBA running scripts that were completely untested, which would lead to a lot of round-and-round between the developers and the DBAs while getting the scripts debugged. After a bit of this, and some prodding from our side, they relented.)
I just can't imagine that anyone would want anything running on their database without having a versioned script somewhere so they could review it, look at the change history, redeploy it if need be, etc., etc.
Of course, we're stuck using Merant PVCS as our source control software, and that's the real WTF.
Admin
Admin
I'd have to guess "your sister."
Admin
no, then Mr. D'Amico and others might have an issue
Admin
I gave cbd gummies a whack at with a view the maiden habits, and I'm amazed! They tasted smashing and provided a sense of calmness and relaxation. My importance melted away, and I slept outstrip too. These gummies are a game-changer on the side of me, and I highly commend them to anyone seeking spontaneous pain liberation and think twice sleep.