« Western Digital, OS X, S.M.A.R.T, and Load Count | Main | Oniguruma on OS X Snow Leopard »

January 08, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.


Good advice. One unique field should alone be required for identification!

The same happened with me at 'My Opera', and I had to email the support/feedback team to know my user-name - which came in a month later.

Account Deleted

Well, Obviously ^_^

Basic SQL Example:
SELECT password FROM accounts WHERE username = '%username%'

Not much a need for anything else.


@Jahan Addison: Except that you would never store the password in plain text or even with two way encryption in the database.


Valid remark. Unless they allow more accounts per e-mail address.

Then they need the username (although one might say that then they don't need the e-mail)

Greg Gamble

I totally agree. And why should a password field be unreadable?

Josh Goebel

That's a carry over I think... probably goes back a bit to the days when computers were more shared resources and people didn't have one in every room of their house. Still I see the point... if passwords weren't secure by default I'd want at least the option of making it secure (when people are around).

Although you could argue that should be a client decision... the server just says "hey this is a password field" and then I decide if I want it to be shown or hidden... I think the default should be hidden though.

I have debated not hiding the password though on some projects, but I've always come back to hiding it so far.


Umm.. that IS a client decision.

The server says "hey this is a password field" by streaming 'type="password"'.

The browser (aka the client) decides how to render it.


And to all the sites that automatically reset your pass on submitting the form...
What if some bozo just entered my info?
Give a confirmation link!

The comments to this entry are closed.

About the Author

Rails and Ruby Projects