Alas, another PHP topic. So, I have a login form. It works just like it should, but I realized I should allow clean usernames to be used. A clean username, basically, is an all-lowercase version of the original username (because some people are too lazy to use the shift key where necessary). So:
I wouldn't think you need to have a "clean_username" column at all. MySQL non-binary columns (any column containing text that's not a "blob") are case-insensitive by default (meaning "User", "user" and "uSeR" will all match). Setting a username to lowercase is hardly clean, though; by not cleaning the string (stripping slashes and running it through real_escape_string, or disallowing non-alphanumeric characters completely), you're opening up your database to injection.
It also might be a bit counter-productive having a "password" and "safe_password" column. The idea of storing the md5 hash as a password is so if anyone manages to get into your database, it's impossible for them to see the actual password. Instead, they'd see an md5 hash that typically can't be reverse-engineered. Unless, of course, someone was stupid enough to put in a password like "apple", in which case there are dozens of sites out there that have a database of common md5 hashes.
Anyway, by having "password" and "safe_password", an attacker will still be able to see the "password" column if he manages to get in.
Oh...should note something I discovered the other day. In PHP5, an empty array still counts as "1". So, if $_POST is empty, count($_POST) is still giving you a result of "1". Might be better to just use !empty($_POST), or count($_POST) == 2.
That was just a basic code of what I was using. I do have the stripslashes() and mysql_real_escape_string() functions set up. Hrm, okay. But, how come it still gives me an error if I try to sign in with user as opposed to User? And yeah, I'll update that whole password business.
It looks fine to me. If all you're doing is making sure the username is lowercase. I just don't see it nessesary to do.
Also, I agree with fixtik. You're hardly cleaning these things. A malicious user could very easily add code and execute SQL statements.