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?
Daniel Porowski
dporowski@myrio.com
425-368-4426
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.
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?
- try 3.2.2
- try from scratch: from new user page and then step by step
Scanned on 11 Nov 2004 17:49:28
Daniel Porowski
dporowski@myrio.com
425-368-4426
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@
Appreciated!
Never thought I’d be this happy that the usernames were arbitrary… :)On Nov 11, 2004, at 10:59 AM, Ruslan U. Zakirov wrote:
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?
- try 3.2.2
- try from scratch: from new user page and then step by step
Scanned on 11 Nov 2004 19:00:20
Daniel Porowski
dporowski@myrio.com
425-368-4426