• P (unregistered)

    I don't see "sending raw SQL query to server" SQL injection galore, so this is still not a WTF.

  • (nodebb)

    This must be "let's do stupid things with other peoples' money" week on WTF. Interesting fact. Various banks processed these relief loans that came from the US Small Business Administration to help businesses get through the epidemic. The small banks had their krewes work overtime (at home) filling out the paperwork for their customers, and handled a lot of loans quickly. The big banks gave the project to their programmers. I guess the sprint hasn't ended yet, no loans.

    Too big to succeed?

  • (nodebb)

    Is this all client-side JS, or have I blinked and missed switchover to server-side JS?

  • my name is missing (unregistered)

    I once worked on a codebase with 4 different implementations of linked lists in C; over time they had begun to evolve and merge together into new forms as the usages were accidentally mixed up.

  • (nodebb) in reply to Pawel Kraszewski

    I don't know what's worse, client javascript calling the database, or the existence of server javascript.

  • (nodebb)

    Would I be happier not knowing how stringtoDate() is implemented?

  • WhatEver (unregistered)

    Ah yes, hard coded credentials. I work with a global level company that has hundreds of intranet installations around the world. Their main application also has plain text, hard coded DB credentials in the user interface, and if you know where to look they are easily accessible. But the kicker is that the credentials are for the "sa" account fo the DB. I raised this issue well over 10 years ago when I first became aware of it, but nothing has changed.

    They also have a simplistic RDP password for logging into various systems that control things. But recently they have moved to increase security on the latest ones to be rolled out - the newest version of the password is teh same as the old one, but has an exclamation mark appended to it.

  • doubtingposter (unregistered) in reply to Mr. TA

    client side javascript isn't worse than php. Which already exists in abundance. So in my opinion this is strictly better than client side java script contacting a DB directly, with hardcoded credentials.

  • Brian (unregistered)

    Oh wow, this is... special.

    I love how the first alert message is in French but the second is English. Nice to assume your users are bilingual.

    And that date validator, which takes the date components in any order. Is 12-01-10 Dec 1 2010, Jan 12 2010, or Jan 10 2012? Eh, who cares as long as it looks vaguely date-y.

  • Robert (unregistered)

    Brilliant!

    Brilliant_!

  • Prime Mover (unregistered) in reply to Robert

    Don't you mean:

    Brillant!

    Brillant_!

    ?

  • hpoe (unregistered)

    The events that lead to this product:

    Event 1: Dyslexic salesperson walks into wrong business to meet with client.

    Event 2: Salesperson starts lying about what company offers because he gets paid on commission and the company could sale toaster for all her cares, he just needs the pay check.

    Event 3: Client places big order, engineers protest that the company doesn't make a payroll operations application, they've never made payroll solutions and they can't do something like that on the schedule proposed.

    Event 4: Management tells engineers the deal is signed so quit whining and do their job.

    Event 5: The developers start working furiously night and day for weeks to try and deliver on time. Code quality suffers greatly as the 3rd straight week begins.

    Event 6: The engineers make the deadline barely but what is delivered is a buggy unusable unholy mess that causes widespread despondency and self mutilation.

    Event 7: The managers realize they are going to make a fortune charging the customers through the nose for upgrades.

  • (nodebb) in reply to doubtingposter

    I was joking of course. I think you meant server side Javascript. Maybe it's better than PHP, but managed compiled platforms like Java and .NET are far superior to both. So...

  • (nodebb) in reply to doubtingposter
    So in my opinion this is strictly better than client side java script contacting a DB directly, with hard-coded credentials.
    Which is exactly what this is: hard-coded credentials in the client-side JavaScript, to contact the database server directly. That is why there is middle-ware, to hide the database server behind business rules, filtering, application permissions and stuff. So your chain of connections is Web browser - Web-server - Application server - Database. The web-server just acts to feed stuff to the application server, so the application server does not have to deal with that part; the application server just gets completed requests and form results. Only the web-server has public exposure. The database server only talks with the application server and the application server takes care of all the other stuff.
  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Robert

    Brillant!

    Brillant_!

    FTFY

  • Fnord (unregistered)

    Wait, is there such a thing as a non-ugly regex (at least one that does something nontrivial)?

  • WTFGuy (unregistered)

    I suddenly have a strange feeling somebody said something about regexes & ugliness, but I can't see any such comment now. Weird.

  • Je suis an anglophone (unregistered)

    The real WTF is that one of those functions throws up an error message in French, while the other does it in English. I guess that's their weak attempt at serving their customers in multiple languages.

  • Calli Arcale (unregistered) in reply to Brian

    Perhaps they are Canadian and this is an attempt to conform to Canadian bilingual marking rules?

  • (nodebb)

    I love that they have these two lines, resulting in the 'd' being a string before immediately appying an isNaN check:

    {code} d = Date.parse(dateValue.substring(0,4) + '-' + dateValue.substring(4,6) + '-' + dateValue.substring(6,8)); if(isNaN(d)) {code}

    Apologies if I've formatted the code incorrectly

  • Fizzlecist (unregistered)

    Another WTF not mentioned yet is the different implementations of their date validation. The function validateDateValue tries date formats that aren't in validateDateValue_ and vice-versa

  • Chris (unregistered) in reply to Watson

    Pretty sure the first thing stringToDate() does is make sure it's been given a valid date string. It probably does this by calling validateDateValue().

  • doubtingposter (unregistered) in reply to Mr. TA

    I did indeed mean server-side. And yes, there are many options better than server-js or php. But if better alternatives stopped people from doing things the wrong way, this site wouldn't exist ;)

    I wouldn't want to work on a project with server-side js, but I understand that they exist and that there are some people who would be able to write a server application in it that isn't shit.

  • eric bloedow (unregistered)

    reminds me of a program i wrote for a class project. i forgot to make sure the month is a number 1-12. so when the NEXT part of the program tried to perform a Table look-up using "month 31", the program crashed so hard it caused a core-dump!

  • Randal L. Schwartz (google)

    The shortest regex that can accurately validate email is at http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html. Well, you can make it shorter if you have named subexpressions.

  • jgh (unregistered)

    A client can never know if a URL or email address is valid, the only way to find out is to attempt to fetch it/send to it and see what the response is. It's entirely the server at the other end that decides whether what you are attempting to fetch is something it can serve or not. Psychic ability is not yet an installable programming library.

  • Some Ed (unregistered) in reply to jgh

    Yes, but it's possible to validate whether a URL would be legal per the standards. The utility of checking that rather than just passing the URL off to something that can say if the page really exists or not is that it's generally easier to fix security holes in the validation routines that you wrote and can theoretically update readily than it is to fix the security holes in the web server software that you didn't write, might not have access to, and even if you do, it's millions of lines long and you don't know where the security holes might be (except, of course, "everywhere".)

    Of course, there are a lot of perfectly valid URLs that can also exploit some security holes, so validation routines tend to be a bit more restrictive than the actual standards. But those are the internal validation routines. The stuff that gets open sourced tends to be more permissive, and we just use it as an initial pass to make the stuff we care about not need to worry about as many details.

Leave a comment on “WTFYou, Pay Me”

Log In or post as a guest

Replying to comment #514286:

« Return to Article