Norway


There are certain programming problems that I generally say you shouldn’t try and solve yourself. Dates, of course, are a big one. They’re more complicated than you think, and unless you want to make managing a date handling library your life’s work, just use someone else’s.

Encryption is another. There are so many subtle ways to do it wrong that unless it’s your specialty, you’re going to screw it up. Another similar problem is .

Artyom was having a bit of an authentication problem. He had inherited a Portal, written by a “ minded” developer. Since this developer was “ minded”, they took “common sense” measures, like using JavaScript to prevent copy/pasting into the password field, and to prevent password managers from running. That was annoying enough, especially considering Artyom favored a 34 character password, but strangely… it never worked on the first attempt. Artyom always had to enter the password twice.

Fortunately, the authentication method was well documented, and explained exactly what was going on:

if (Authenticate())
{
    // If user knows password, he or she will be able
    // to type it in again.
    // If he or she has just guessed, he or she will
    // fail at the second attempt
    ShowAuthFailureBox();
    if (Authenticate())
    {
        authorized = true;
        Execute();
    }
    else
    {
        ShowAuthFailureBox();
    }
}
else
{
    ShowAuthFailureBox();
}
- proget icon - Authentication Failure – The Daily WTF [Advertisement]
Ensure your software is built only once and then deployed consistently across environments, by packaging your applications and components. Learn how today!



Source link

LEAVE A REPLY

Please enter your comment!
Please enter your name here