[rt-users] Unprivileged users unable to authenticate?

[Ruslan U. Zakirov]

Daniel Porowski wrote:
> Only log entries reflect a failed login...  Nothing more than that.  No 
> db errors, nothing, and I've got RT set to debug log level.
> 
> Same thing is now happening on 3.2.2.  New users work just great, and 
> not all of the preexisting users are affected.  The ones that are, 
> however, are identical to the working ones, even on the DB level.  I've 
> gone through and compared the user tables, etc for each one, and they 
> line up perfectly.
> 
> One thought though, is there a limitation where the usernames must start 
> with an alpha character?  These are numeric only, which is the only 
> thing I can think might be throwing it.
Gotcha!!!
This is an issue. RT uses complex function RT::User->Load that 
interprete argument as ID if arg. contains only digits. Problem here is 
that RT doesn't reject creation of users with such name.

Workaround: use none digit prefix/suffix.

			Best regards. Ruslan.

PS: Sent Bcc to rt-bugs@

> 
> It doesn't seem to be a priv. vs unpriv. issue either, since toggling 
> that on and off for the affected users has no effect, either on the 
> results or the log entries.
> 
> Could this be a mysql-related issue?  I'm not above upgrading THAT guy, 
> either...
> 
> 
> On Nov 11, 2004, at 9:49 AM, Ruslan U. Zakirov wrote:
> 
>> Daniel Porowski wrote:
>>
>>> Okay, with RT 3.2.1 on mysql/linux, I'm running into an issue where 
>>> some of my unprivileged users are unable to log into the web 
>>> interface due to authentication issues.
>>> It's not user error--I've tested it myself using known 
>>> passwords/usernames.  The accounts are active in RT, don't show 
>>> disabled in either the GUI or the database, and the password hashes 
>>> in the DB match those on accounts with working, known passwords.  
>>> Everything about these users looks just fine in the DB and the GUI, 
>>> it's just that they can't log in.  Changing their passwords in the 
>>> GUI has no effect, toggling them active/inactive in the GUI has no 
>>> effect...  Nothing seems to fix this.
>>> Anyone run into this before?
>>
>> IMHO, no.
>> Logs?
>>
>> 1) try 3.2.2
>> 2) try from scratch: from new user page and then step by step