A teeny tiny WTF, but still...



  • I am required, according to my project manager, to add a required field validator to the login page's username and password fields in our application. Apparently some users must be notified that they are both required and neither one is optional. These people should have their Internet Licenses revoked.



  • I'm not sure about this one.  There are systems out there that do not require both and it will stop server traffic for people that hit enter by mistake before they are finshed.

    The real WTF is that the enter key is above the shift key; everyone that worked on 3270 terminals knows that it is supposed to be below the shift key...



  • >>The real WTF is that the enter key is above the shift key; everyone that worked on 3270 terminals knows that it is supposed to be below the shift key...

     just rotate the keyboard 180



  • @elbaz said:

    I'm not sure about this one.  There are systems out there that do not require both ...

    What kind of system presents both username and password fields but can give a successful login when one of those is left blank? None. Unless the system allows blank passwords (which this one absolutely does not).



  • [quote user="elbaz"]

    I'm not sure about this one.  There are systems out there that do not require both and it will stop server traffic for people that hit enter by mistake before they are finshed.

    The real WTF is that the enter key is above the shift key; everyone that worked on 3270 terminals knows that it is supposed to be below the shift key...

    [/quote]

    Exactly. Not even close to a WTF. 



  • [quote user="djork"][quote user="elbaz"]

    I'm not sure about this one.  There are systems out there that do not require both ...

    [/quote]

    What kind of system presents both username and password fields but can give a successful login when one of those is left blank? None. Unless the system allows blank passwords (which this one absolutely does not).[/quote]

    I think you have completely missed the point. 



  • @Jeff S said:

    I think you have completely missed the point. 

    I must have. I'm saying that it's kind of inane to have separate client-side logic to validate that the user did indeed enter a username and a password before doing authentication, when leaving either one of those out would amount to a failed authentication and an error message anyway. No password = wrong password. So, why bother being redundant by flashing "required field" on the password field instead of just letting the user go ahead and try logging in without a password?



  • >why bother being redundant by flashing "required field" on the password field instead of just letting the user go ahead and try logging in without a password?

    I dunno, maybe to keep the number of round-trips to the server as low as possible? 



  • [quote user="djork"][quote user="Jeff S"]

    I think you have completely missed the point. 

    [/quote]

    I must have. I'm saying that it's kind of inane to have separate client-side logic to validate that the user did indeed enter a username and a password before doing authentication, when leaving either one of those out would amount to a failed authentication and an error message anyway. No password = wrong password. So, why bother being redundant by flashing "required field" on the password field instead of just letting the user go ahead and try logging in without a password?[/quote]

    Why ever have client-side validation then? Assuming you have written good server-side code, should the client ever validate any input at all?

    As already mentioned, anytime you can reduce round-trips, or provide instant feedback for your users without having to have them wait for a post, then get a message, then click back or hit a button and go back again to finish up, it's a good thing .. don't you think? 



  • @Jeff S said:

    [quote user="djork"][quote user="Jeff S"]

    I think you have completely missed the point. 

    I must have. I'm saying that it's kind of inane to have separate client-side logic to validate that the user did indeed enter a username and a password before doing authentication, when leaving either one of those out would amount to a failed authentication and an error message anyway. No password = wrong password. So, why bother being redundant by flashing "required field" on the password field instead of just letting the user go ahead and try logging in without a password?[/quote]

    Why ever have client-side validation then? Assuming you have written good server-side code, should the client ever validate any input at all?

    As already mentioned, anytime you can reduce round-trips, or provide instant feedback for your users without having to have them wait for a post, then get a message, then click back or hit a button and go back again to finish up, it's a good thing .. don't you think? 

    [/quote]

    I agree that reducing round-trips is a Good Thing. I just stand by the idea that it's silly that we have to notify that the username and password fields are required. That's all.



  • [quote user="djork"][quote user="Jeff S"][quote user="djork"][quote user="Jeff S"]

    I think you have completely missed the point. 

    [/quote]

    I must have. I'm saying that it's kind of inane to have separate client-side logic to validate that the user did indeed enter a username and a password before doing authentication, when leaving either one of those out would amount to a failed authentication and an error message anyway. No password = wrong password. So, why bother being redundant by flashing "required field" on the password field instead of just letting the user go ahead and try logging in without a password?[/quote]

    Why ever have client-side validation then? Assuming you have written good server-side code, should the client ever validate any input at all?

    As already mentioned, anytime you can reduce round-trips, or provide instant feedback for your users without having to have them wait for a post, then get a message, then click back or hit a button and go back again to finish up, it's a good thing .. don't you think? 

    [/quote]

    I agree that reducing round-trips is a Good Thing. I just stand by the idea that it's silly that we have to notify that the username and password fields are required. That's all.[/quote]

    Your statements contradict each other.  You say it is a good thing to prevent unneeded round trips, but then say it is silly to put in client side validation that prevents an unneeded round trip.  Where's the WTF here?



  • I'm with djork on this one.  It is kind of ridiculous.  Besides, server traffic is rarely a concern when you are talking about one page with a little html, a few hundred bytes doesn't add up to much.  I think the real wtf here is that djork's supervisor is concerned about such mundane details.



  • I gotta side with the OP, you shouldn't have to tell people that both fields are required. If you don't require a password, then why bother putting the box there?

    There are plenty of stories like that from my job. Part of my duties are setting up accounts on my company's web server. I can't count how many times someone will ask me "Is that password case-sensitive?"

    I was having a bad day on one such occurrence, and I responded with something like "Nope, for the first time in your life you've been given access to a website that has case-insensitive passwords, enjoy your stay."

    Sorry but sometimes the users are the biggest WTF.



  • What is a system that gives you a password field and does NOT require you to enter anything?  WINDOWS!  I don't see what's wrong with this.  It takes less than 20 minutes to add this code.  Probably 3-5 minutes if you are familiar with the code.  If your password authentication takes a while (say 5-10 seconds round trip) that means you will end up saving clients far more than 5 minutes in the long run. 

     

    Manni,

    Are you seious?  you do know there are such things as case-insensetive passwords. 



  • I've registered with far more websites than I ever thought I'd have to. Web-based email accounts, developer forums, online banking, and so on and so on.

    Never once have I ever been given access to a system that used a case-insensitive password. Unless you count that one site that required me to choose an 8-digit number as my password. And yes I'm serious about that.



  • [quote user="Manni"]

    I've registered with far more websites than I ever thought I'd have to. Web-based email accounts, developer forums, online banking, and so on and so on.

    Never once have I ever been given access to a system that used a case-insensitive password. Unless you count that one site that required me to choose an 8-digit number as my password. And yes I'm serious about that.

    [/quote]

    Lots of passwords are not case sensitive.  Here's a quick non-scentific sampling:

    http://www.google.com/search?q="password+is+not+case+sensitive"

    only returned about 10,000 results ....

     



  • [quote user="roto"]I'm with djork on this one.  It is kind of ridiculous.  Besides, server traffic is rarely a concern when you are talking about one page with a little html, a few hundred bytes doesn't add up to much.  I think the real wtf here is that djork's supervisor is concerned about such mundane details.
    [/quote]

    Authentication often requires a database hit as well. and the whole point is to make the experience smooth for the user -- if I have a slow net connection, and I don't hit the TAB key just right so I accidentally type "usernamepassword" all in the username field and hit ENTER, it's nice to quickly be informed that something is wrong without waiting to the form to post, the "something is wrong" page to load, and then to hit the back button and try again.

    It's threads like this one that clearly show the different types of programmers out there -- those that see the small picture and focus on their own little world, and those that are able to see the big picture.

     



  • [quote user="Manni"]

    I've registered with far more websites than I ever thought I'd have to. Web-based email accounts, developer forums, online banking, and so on and so on.

    Never once have I ever been given access to a system that used a case-insensitive password. Unless you count that one site that required me to chooseA an 8-digit number as my password. And yes I'm serious about that.

    [/quote]

     And have you tried an upper case version of all your passwords on these sites at least once? You would be surprised on how many sites I have worked on that store passwords in plain text (bad move, I know, but not my design) and usually Microsoft SQL is case-insensitive when it comes to queries (I believe mySQL also, though I remember Oracle not being) so it doesn't matter if you enter it in upper or lower case, only matters if you encrypt it first.
     



  • [quote user="Jeff S"]

    Authentication often requires a database hit as well. [/quote]

    Of course, although if the user hasn't entered a value for a required field, it shouldn't get that far (even if it does make it to the server). 

    [quote user="Jeff S"]and the whole point is to make the experience smooth for the user -- if I have a slow net connection, and I don't hit the TAB key just right so I accidentally type "usernamepassword" all in the username field and hit ENTER, it's nice to quickly be informed that something is wrong without waiting to the form to post, the "something is wrong" page to load, and then to hit the back button and try again.[/quote]

    I'd consider that to be poor design - in my opinion (and experience), error messages should be displayed on the page to which they relate, and anything the user has input should be preserved. That doesn't excuse the unnecessary round-trip, of course...

    I agree with the basic idea though; not everyone has superfast ADSL or corporate connections at their disposal, and anything that can be reasonably done to improve the user experience should be done. (Constraints willing, of course) 

    [quote user="Jeff S"]It's threads like this one that clearly show the different types of programmers out there -- those that see the small picture and focus on their own little world, and those that are able to see the big picture.[/quote]

    I agree, although I would point out that regardless of client-side validation, you must of course still implement server-side validation as well (and I realise that you didn't say it shouldn't be). Never trust the client...



  • Validation is not done for the same reason in both places. 

    Clients validate data for the convenience of the user.

    Servers validate data for the security of the system.

     



  • so tell us.  how long did you spend fulfilling this outrageous request?



  • @tster said:

    so tell us.  how long did you spend fulfilling this outrageous request?

    Note the title: "A teeny tiny WTF"


Log in to reply