• jkupski (unregistered) in reply to Smash King
    Smash King:
    I like how descriptive he gets when naming his variables. Who wouldn't know the meaning of $q and $chumbawumba ?
    $chumbawumba implies that if your server gets knocked down, it'll get up again, and that, in fact, you're never going to keep it down.
  • (cs)

    This must have been the login page for the system used by Lehman Brothers to purchase real estate

  • JarFil (unregistered)

    Warning: $chumbawumba not equal $mambozambo in wongobongo::bingbing(boom, kaboom, woom)

  • (cs) in reply to Kermos
    Kermos:
    Meep3d:
    The real WTF, and something I see every day, is why just about everyone feels the need to abstract the mysql functions behind another layer of obfuscation?

    I've never heard a convincing reason for this and no doubt the first thing you have to do when looking at someone elses code is have to figure out the bizaare idiosyncrasies of their particular reimplementation.

    One convincing reason is that if you ever need to switch databases from MySQL to something else you don't have to rewrite all your code. Assuming that the SQL code is compatible you'd only need to rewrite the class that handles the API access.

    Exactly. A couple of years back, I inherited an application which I call "the Frankenstein monster". It displays schedule information for multiple operating rooms in multiple hospitals of a large health care system. Display of this information is filtered based on the user's membership in various Active Directory groups.

    When it came to me, the app was several years old and had been maintained/updated by quite a few developers who had come and gone. Originally it had been written for two hospitals, which shared an Informix database. Later it was expanded to include several additional hospitals, some of which used the Informix database and some of which used Oracle; and so the data access section had been cobbled together to perform separate queries and then massage these into a single display. This had been done quite hurriedly, to judge from the quality of the code, which was a sickening spaghetti mess of string manipulation to create SQL queries in-line based on a huge amount of criteria which may or may not have been specified by the user.

    My first assignment was to update the application to add another hospital; one which used a SQL Server database.

    Given the timeline, I had no choice but to go in and copy the style used by my mad scientist predecessors, patching and stitching and hacking until the thing on the slab twitched and shuddered and opened its jaundiced eye. I did so, but I explained to my manager the condition of the application and advised him that it was in dire need of a complete redesign and rewrite from the ground up. He was sympathetic and even went as far as authorizing the project; but it had no champion and was shelved as soon as something more important came up.

    Fast-forward a year: the Informix database is being dropped and its data moved to the Oracle database. This means that all but one of the hospitals will now be using Oracle, with SQL Server the odd one out. At this time the application owners presented us with a request for some fairly extensive revisions to the data being displayed and to the UI. The project was fired up again, this time with a little muscle behind it, and I got the go-ahead to focus on abstracting the data access layer.

    What does all this have to do with the quotes above? My point is that abstracting the data access will prevent the necessity of hacking and patching the application in the future event of more database changes. Suppose they merge the SQL Server data into Oracle? Suppose they add a hospital that uses MySql? It should only be necessary to rework the data access layer. The application should never even know which database is being accessed. It sends a request based on specified criteria, and it gets the results back and displays them. It's the ol' "black box" approach.

    And that's why abstraction is a good thing.

  • Thunder (unregistered) in reply to Meep3d
    Meep3d:
    $q->query($sql);

    The real WTF, and something I see every day, is why just about everyone feels the need to abstract the mysql functions behind another layer of obfuscation?

    I've never heard a convincing reason for this and no doubt the first thing you have to do when looking at someone elses code is have to figure out the bizaare idiosyncrasies of their particular reimplementation.

    Some good reasons have been posted, but I typically have a simpler one - in real life, most applications don't tend to swap databases like old clothes. Instead, there's a lot of common housekeeping around error handling and query processing that would otherwise have to be coded separately for each query. When you're handling all of them in the same way, there's generally no reason to do that -- a simple abstraction layer can save a ton of repetitive coding.

    In other words, basic computer programming knowledge should answer that question for you. It's the same reason we make functions to contain /any/ oft-repeated chunk of code.

  • Matt Bradley (unregistered)

    I imagine you snipped out the comment which immediately preceeded this code:

    // Replace the following with a proper user authentication mechanism once we've finished testing the application.

    No? Oh dear.

  • Zap Brannigan (unregistered) in reply to Matt Bradley
    Matt Bradley:
    I imagine you snipped out the comment which immediately preceeded this code:

    // Replace the following with a proper user authentication mechanism once we've finished testing the application.

    No? Oh dear.

    That's what I was thinking too. This was not intended to be production code.

  • Ben (unregistered) in reply to Smash King
    Smash King:
    I like how descriptive he gets when naming his variables. Who wouldn't know the meaning of $q and $chumbawumba ?

    It is easier to remeber once you realize that the one item in the db is in fact 'chumbawumba'

  • Vessini (unregistered) in reply to DaveK
    DaveK:
    java.lang.Chris;:
    Logging in was slow, and he leaked connections by not closing them - if the database ran out of connections before the garbage collector kicked in he was straight outta luck.
    I do not believe the "S" in "SOL" means what you think it means.
    BrianK:
    To quote a great movie... "INCONCEIVABLE!"
  • I walked the dinosaur (unregistered)

    Rick Astley would never knock you down, so you wouldn't need to get back up again.

  • Al (unregistered) in reply to ParkinT
    ParkinT:
    Perhaps the application never gained more than one user. Plenty of room for growth!!

    I just wanted to point out the while loop- only the last record in the user database is ever checked. So no need to worry about concurrent logins by different users!

  • (cs) in reply to Bejesus
    Bejesus:
    Sadly, that's significantly more elegant than most Single Sign On solutions I've encountered...
    That doesn't say much. It is easy to be simple if you don't have to be right. "1 + 1 = 1" is very simple -- only 3 different symbols that require meaning.
  • anonymous (unregistered)

    It DOES rule out SQL injection vulnerabilities, though. :)

  • ifatree (unregistered) in reply to BK
    Classic example of bad naming. Had the table been named SingleWebPassword and its single column [password] , there wouldn't be WTF

    this was also my first thought... this looks like the kind of code you'd get from having someone work on a complicated logon solution for a few weeks, then drastically scaling back the requirements to such a degree it's easier to just chop out 90% of the code and leave what you see here.

    it says he's using a sesion variable, so more than likely there's an unshown, overcomplicated session management system to match the oversimplified login system. actually, that type of out-of-band session passing back to index IS how you do single sign on (you can't set a $_SESSION var on the login server and have Apache give it to your app on another server without passing it somehow through the request from the browser. personally, i'd make custom headers instead of passing through $_GET, but whatever's clever.

  • (cs) in reply to Code Dependent
    Code Dependent:
    A couple of years back, I inherited an application which I call "the Frankenstein monster".
    I can see the accompanying Will now.

    "Dear Codey, I know you were expecting my book shop, or perhaps your uncle's little place in Marlow, but what with this internet thing absolutely killing the book trade, and the credit crunch putting a bit of a damper on the property market, we had to trade those in for a video on vegetarian cookery.

    I hope you'll be pleased with the contents of the casket (enclosed) as a token of our love. Your uncle rummaged around in the tool box to try to find the wall wart, but we seem to have misplaced it somehow. Never mind. Lightning seems to work just as well, and it's so much more environmentally friendly, don't you think? The villagers offered to chip in with some firewood, which I think was simply sweet of them.

    Your Auntie Wooly and Uncle Bish"

    Mind you, I do think that "Look on my works, Ye mighty, and despair" sums up the code in the OP quite well.

  • (cs) in reply to BrianK
    BrianK:
    To quote a great movie... "INCONCEIVABLE!"
    Actually, even Fezzik would have done a better job than this.
  • ifatree (unregistered) in reply to beltorak

    simple you say? i'd argue that understanding the rightness "1+1=1" is beyond the ability of most humans, much less modern computers. ;)

    also, if you "don't have to be right", and only care about simplicity, "1 + 1 = 1" can be represented in your program as a single symbol and it doesn't have to worry about symbolic meaning at all. if you have "1", "+", and "=" in your bag, though, and think you have a meaningful program, you're probably not talking about the mathematical/symbolic meaning either.

  • (cs) in reply to real_aardvark
    real_aardvark:
    Mind you, I do think that "Look on my works, Ye mighty, and despair" sums up the code in the OP quite well.
    When I get finished, it will be more like, "Nothing beside remains round the decay of that colossal wreck."
  • Jiff jensen (unregistered)

    Brilliant. New meaning to the word simple! LOL

    Jiff www.anonymize.us.tc

  • Steve (unregistered) in reply to ParkinT
    ParkinT:
    Perhaps the application never gained more than one user. Plenty of room for growth!!
    I worked for a startup that *wished* we had one user.
  • Daniel (unregistered)

    Very simple indeed... the password is actually the username.

  • (cs) in reply to jkupski
    jkupski:
    Smash King:
    I like how descriptive he gets when naming his variables. Who wouldn't know the meaning of $q and $chumbawumba ?
    $chumbawumba implies that if your server gets knocked down, it'll get up again, and that, in fact, you're never going to keep it down.

    And here I was thinking it was because Chumbawumba were a one(password)hit wonder.

  • Death (unregistered)

    Ive actually written something like this. For debugging purposes. With a big FAT waning in the config file to NOT turn it on unless you are beyond doubt sure its your testing server and you know what you are doing. With this bit, I refuse to believe this snippet was not wrapped in if(AUTH_DEBUG){<your simple bitA>}

  • Valerion (unregistered)

    $chumbawumba?

    "I get kicked out, but I login again, they're never gonna keep me out..."

    Reminds me of a guy we had who used to name all his variables after fish: $pilchard = $turbot + $halibut

  • uncomprehending (unregistered)

    so he checked the password against the user name? that IS 'simple'.

  • Chris (unregistered) in reply to Code Dependent
    Code Dependent:
    Kermos:
    Meep3d:
    The real WTF, and something I see every day, is why just about everyone feels the need to abstract the mysql functions behind another layer of obfuscation?

    I've never heard a convincing reason for this and no doubt the first thing you have to do when looking at someone elses code is have to figure out the bizaare idiosyncrasies of their particular reimplementation.

    One convincing reason is that if you ever need to switch databases from MySQL to something else you don't have to rewrite all your code. Assuming that the SQL code is compatible you'd only need to rewrite the class that handles the API access.

    Exactly. A couple of years back, I inherited an application which I call "the Frankenstein monster". It displays schedule information for multiple operating rooms in multiple hospitals of a large health care system. Display of this information is filtered based on the user's membership in various Active Directory groups.

    When it came to me, the app was several years old and had been maintained/updated by quite a few developers who had come and gone. Originally it had been written for two hospitals, which shared an Informix database. Later it was expanded to include several additional hospitals, some of which used the Informix database and some of which used Oracle; and so the data access section had been cobbled together to perform separate queries and then massage these into a single display. This had been done quite hurriedly, to judge from the quality of the code, which was a sickening spaghetti mess of string manipulation to create SQL queries in-line based on a huge amount of criteria which may or may not have been specified by the user.

    My first assignment was to update the application to add another hospital; one which used a SQL Server database.

    Given the timeline, I had no choice but to go in and copy the style used by my mad scientist predecessors, patching and stitching and hacking until the thing on the slab twitched and shuddered and opened its jaundiced eye. I did so, but I explained to my manager the condition of the application and advised him that it was in dire need of a complete redesign and rewrite from the ground up. He was sympathetic and even went as far as authorizing the project; but it had no champion and was shelved as soon as something more important came up.

    Fast-forward a year: the Informix database is being dropped and its data moved to the Oracle database. This means that all but one of the hospitals will now be using Oracle, with SQL Server the odd one out. At this time the application owners presented us with a request for some fairly extensive revisions to the data being displayed and to the UI. The project was fired up again, this time with a little muscle behind it, and I got the go-ahead to focus on abstracting the data access layer.

    What does all this have to do with the quotes above? My point is that abstracting the data access will prevent the necessity of hacking and patching the application in the future event of more database changes. Suppose they merge the SQL Server data into Oracle? Suppose they add a hospital that uses MySql? It should only be necessary to rework the data access layer. The application should never even know which database is being accessed. It sends a request based on specified criteria, and it gets the results back and displays them. It's the ol' "black box" approach.

    And that's why abstraction is a good thing.

    A database abstraction layer is a good thing. A home-grown database abstraction layer is rarely a good thing. I've seen both (and had to work on both), including a system that used a home-grown database abstraction layer on TOP of a pre-built abstraction later (ADODB) and the home-grown stuff can easily turn into a mess if you don't have a clear purpose to what you are doing beforehand.

    The real problem is that a lot of the crap that you see where people tried to write their own database abstraction functions is that they obviously didn't plan very well and it shows.

    That being said, I usually use ADODB for all my PHP projects. Why reinvent parameterized queries or force my clients to use mysqli? Why waste time writing my own database abstraction layer when their is a proven one out there already?

    To the original poster of this "real WTF": $object->query($sql); is 10:1 a call to the ADODB query method, not something home-grown.

  • ron (unregistered)

    Evil IT Resources page http://resursi.wordpress.com (IT management in Eastern Europe, HR, politics and other things)

  • OBloodyhell (unregistered) in reply to Simple User
    Simple User:

    On second thought, couldn't be a bank. They couldn't work out how to make a site usable if it was the last step between them and a Congressional bailout!

    To be honest, Bank of America's website is at least moderately well done.

    And it works fine with Opera.

  • Brian (unregistered)

    That code not only features Security Through Obscurity, it also has a great password policy. Assuming a new user gets added at least every 90 days!

  • Wolf (unregistered)

    I can do better than that... No user, no passwords, no content... Hell, I can do it without web page...

    Setting a new standard for "simple" XD

  • (cs) in reply to Code Dependent
    Code Dependent:
    real_aardvark:
    Mind you, I do think that "Look on my works, Ye mighty, and despair" sums up the code in the OP quite well.
    When I get finished, it will be more like, "Nothing beside remains round the decay of that colossal wreck."
    A rather late reply; but, OK, you beat me.

    Care to play a game of Hive? I'm absurdly good at that.

  • OhDear (unregistered)

    At least it is immune to an SQL injection attack.

Leave a comment on “Keeping It Stupid Simple”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article