Can not signin with username is number

If the username is number example: (123456), I can not login.

help me! thanks

I can confirm this. I just tried and a username of
123456 does not work but a username beginning with a number, does (ie 1user).

Investigating now.

I'm kind of at a loss right now on that one. It's obvious that an initial problem was that if a username is numeric, it looks up the user by their id. I fixed that on my system and can get it to find a user, but I cannot get a user with a purely numeric username to login. I'll keep looking when my eyes are fresher. Sorry about that. I've never come across this issue.

Thanks you for sppport

The problem is (was?) in User::find().

Code such as this will solve the problem:

if (is_numeric($user) && $user < 10000) {
user_id...
} else {
...

(Sent previously in PM to mudmin, including here for documentation purposes)

Good call on that one.

Hello! Thank you for this excellent framework!
I got this same problem, I need the username to be just numbers (the personal ID of students) and the numbers may be between 11000000 and 50000000. I create the users but I can't log in. Is this already solved or is a fact that the framework cannot handle purely numeric usernames to login?
Thank you!!

There is a trick to it. Because the system will allow you to use your user id instead of username or email, it's looking for the user id. Maybe the best thing.

This is one of the VERY rare times I would tell you to just edit a system file.

If you look at line 57 of users/classes/Users.php you'll see that if the username is numeric, it is looking in the id field.

Change that to username.

You'll obviously have to test it, but that should do the trick. Then just look out for updates that update the user class which is REALLY rare.

I tried but now I can't log in with any user. Maybe I have to modify Validate class? And I don't know where to activate an error log to see what is wrong at login time.
Thank you for your time!

Even more, I commented the IF lines on User.php like this:
public function find($user = null){
if ($user) {
/*if(is_numeric($user)){
$field = 'id';
}elseif(!filter_var($user, FILTER_VALIDATE_EMAIL) === false){
$field = 'email';
}else{*/
$field = 'username';
//}

So this function assigns $field = 'username' without a doubt. And the behavior is the same, can't log in with any user.

One last thing. I rolled back to the original User.php version and when I access to the Administration Panel (admin.php) I see the user 22111222 inside the Logged In Users in the past 24 hours... But I never pass through login.php with that user

I'm not in a place where I can test some code, but I wonder what would happen if you prepended a letter to the beginning of the username (behind the scenes).

Hi!
Finally I prepended a letter to the beginning of the username (not so behind de scenes but it works).
Added a script to "users\login.php" just before the html form declaration. And inside the form tag I added onsubmit="addText()":

<script type="text/javascript">
function addText() {
var input = document.getElementById('username');
input.value = 'u' + input.value;
}
</script>

<form name="login" class="form-signin" action="login.php" method="post" onsubmit="addText()">

That's it. Not the better solution but it works for now.
Thank you very much!
Hernan

A little improvement:

<script type="text/javascript">
function addText() {
var input = document.getElementById('username');
input.setAttribute('type', 'password');
if (input.value != 'admin') {
input.value = 'u' + input.value;
}
}
</script>

With this script you add a letter before any username but admin user.
And before form submit you hide the username text so the user "can't see" that you are adding a letter.

Thanks for this. The automatically converting numbers to user id's was something that was built in to the classes themselves. I need to deal with it properly. I'm adding it to my list.

Any progress on this? I may have stumbled upon something of a solution. I took the advice of the solution of:

If you look at line 57 of users/classes/Users.php you’ll see that if the username is numeric, it is looking in the id field.

Change that to username.

That however didn't seem to work correctly, as what was replied. The session data in the user.php class is still looking at the "id" field.


I went ahead and created a new column in the database userspice db -> users with the name of the column I wanted to hold my new "numeric username", and populated the data. I then changed line 65 ($field = 'id';) to read $field = 'my_new_database_column';, then did a mass find and replace of Session::put($this->_sessionName, $this->data()->id); to change the "id" portion to the name of my new column that holds the "numeric username". It appears to then be successful upon logging in.

I can see that logic working, but that is a lot of tape to fix this problem, we would want to swap out the parts instead of just putting some glue on them.

I've looked extensively into this problem and the class breaks so freaking easily. And the funny thing is, if you make the change or remove the part that uses the ID, it breaks the login, but when you revert it, the session succeeds without even knowing what to do. I'm going to have to look into it further we just haven't had the time to do it unfortunately.

And alternative solution is forcing the ID to be the users username, so on join you can say ID=username during your join process, and then if that ID already exists, die and say this isn't an option. But that is still using glue and shouldn't be used unless you really need this function.

This is an oldie but a goodie!

I have patched this in 4.3.14. This should be released shortly.

The patch was to add an optional parameter on the find function within the Users class, and pass that parameter via the loginEmail function called from login.php and ignore the number. This was so hard to patch because the find function is used to capture the ID to use for the $user calls - so it failed after trying to find the User.

This is an oldie but a goodie!

I have patched this in 4.3.14. This should be released shortly.

The patch was to add an optional parameter on the find function within the Users class, and pass that parameter via the loginEmail function called from login.php and ignore the number. This was so hard to patch because the find function is used to capture the ID to use for the $user calls – so it failed after trying to find the User.

Outstanding! Looking forward to it! Is OAuth going to be written in sometime soon, also? I know Dan mentioned it in the past.

Hi @A.Long:

This has been patched (the usernames). What do you mean about OAuth? Having it implemented? For external vendors to connect to your US install with OAuth or like Facebook/G+ sign in (this is already in).