Can not signin with username is number

[hernancorteshc@hotmail.com]

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

[mudmin]

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).

[hernancorteshc@hotmail.com]

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

[hernancorteshc@hotmail.com]

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.

[mudmin]

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.

[A.Long]

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.

[Brandin]

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.

[Brandin]

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.

[A.Long]

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.

[Brandin]

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).