Recurring Login Problem

Stephen_Turner · January 5, 2005, 8:35pm

Hello,

I’m looking for ideas on a very strange problem. (This is on RT 3.2.2,
Oracle 9, fastcgi, solaris).

The symptom is that you log in to RT, click on any link and you are dumped
back to the login screen. (Logging in again then puts you to the page you
requested).Every time you request a page, you have to go through the login
screen.

I found the problem posted before, and people suggested playing with
browser cookie settings, but nobody reported the problem being solved. I
don’t think browser settings are the answer - here’s what I’ve learned:

the problem happens with these browser/OS combinations:

MSIE 6 - Win XP sp2
Firefox 0.9 - Win XP sp2
Netscape 7 - Win XP sp2
Mozilla - Solaris

the problem does NOT happen with Opera on Windows XP or Solaris.
The problem does not happen while connecting to other RT’s we have set
up, including mysql, Oracle, mod_perl & fastcgi setups. That’s why I don’t
think the problem is a browser config problem.
Session tracking on the server is done with Apache::Session::File, and
for the problem connections, it appears that after login, the user
information is not being stored in the session file. This appears to be the
root of the problem, although I can’t think why this would happen.
This may not be relevant, but I noticed that for problem connections to
the RT home page, autohandler seems to be called twice: once for
index.html, once for bplogo.gif. Successful (Opera) connections show only a
single call to autohandler, for index.html.

So, any ideas?

I’m particularly interested on hearing how the magic of storing the user
attributes in the session data is accomplished. And what might cause this
not to happen.

Thanks,
Steve

Stephen Turner
Senior Programmer/Analyst - Client Support Services
Information Services and Technology (IS&T)

sturner@mit.edu

Jesse_Vincent · January 5, 2005, 9:02pm

Hello,

I’m looking for ideas on a very strange problem. (This is on RT 3.2.2,
Oracle 9, fastcgi, solaris).

SSL?

The symptom is that you log in to RT, click on any link and you are dumped
back to the login screen. (Logging in again then puts you to the page you
requested).Every time you request a page, you have to go through the login
screen.

I found the problem posted before, and people suggested playing with
browser cookie settings, but nobody reported the problem being solved. I
don’t think browser settings are the answer - here’s what I’ve learned:

the problem happens with these browser/OS combinations:

MSIE 6 - Win XP sp2
Firefox 0.9 - Win XP sp2
Netscape 7 - Win XP sp2
Mozilla - Solaris

the problem does NOT happen with Opera on Windows XP or Solaris.

Does it happen with lynx? Does lynx complain about cookies?

Stephen_Turner · January 5, 2005, 9:15pm

At Wednesday 1/5/2005 04:02 PM, Jesse Vincent wrote:

I’m looking for ideas on a very strange problem. (This is on RT 3.2.2,
Oracle 9, fastcgi, solaris).

SSL?

No, this is a non-ssl setup.

Does it happen with lynx? Does lynx complain about cookies?

I forgot to mention this - lynx prompts me to accept/deny the rt cookie. If
I choose “always accept”, I can get around fine. If I choose “never accept”
I have the same recurring login screen problem. I think the reason is
different though. For the graphical browsers that I have the problem with,
the cookie/session stuff seems to be working - I do get a session file with
the name matching the cookie value - it’s just that the user info is not
there. Here’s what one of these session files looks like:

35b63afa7e820eefae63af9277bb3b48
_session_idRT::CurrentUser
Userstable
CurrentUser

Steve

Jesse_Vincent · January 5, 2005, 9:20pm

At Wednesday 1/5/2005 04:02 PM, Jesse Vincent wrote:

I’m looking for ideas on a very strange problem. (This is on RT 3.2.2,
Oracle 9, fastcgi, solaris).

SSL?

No, this is a non-ssl setup.

Does it happen with lynx? Does lynx complain about cookies?

I forgot to mention this - lynx prompts me to accept/deny the rt cookie. If
I choose “always accept”, I can get around fine. If I choose “never accept”
I have the same recurring login screen problem. I think the reason is
different though. For the graphical browsers that I have the problem with,
the cookie/session stuff seems to be working - I do get a session file with
the name matching the cookie value - it’s just that the user info is not
there. Here’s what one of these session files looks like:

That’s very odd. drop in code to YAML::Dump or Data::Dumper the session
to your logs just after it’s loaded and also in the page footer (When
everything should be done already)?

Jesse

Stephen_Turner · January 5, 2005, 10:01pm

At Wednesday 1/5/2005 04:20 PM, Jesse Vincent wrote:

That’s very odd. drop in code to YAML::Dump or Data::Dumper the session
to your logs just after it’s loaded and also in the page footer (When
everything should be done already)?

I dumped the session twice, at the start & end of autohandler. When I type
in user name & pwd and submit, the second dump shows the full user object
stored in the session:

[Wed Jan 5 21:50:48 2005] [debug]: $VAR1 = ‘CurrentUser’;
$VAR2 = bless( {
‘_Class’ => ‘RT::CurrentUser’,
‘_SB_Record_Primary_RecordCache_key’ => ‘Users:id=1265’,
‘table’ => ‘Users’,
‘values’ => {
‘creator’ => ‘1’,
‘comments’ => ‘’,
‘state’ => undef,
‘webencoding’ => undef,
‘password’ => ‘sksdfjw48wert34n’,
‘realname’ => ‘TURNER, STEPHEN’,

<etc, etc cut out>

            }, 'RT::CurrentUser' );

$VAR3 = ‘_session_id’;
$VAR4 = ‘026f81fb6958910a8dd568c6b9d7f97f’;

THEN - when autohandler gets called again (same request, mason component
path “/NoAuth/images/bplogo.gif”), the first dump of the session is:

[Wed Jan 5 21:51:29 2005] [debug]: $VAR1 = ‘_session_id’;
$VAR2 = ‘026f81fb6958910a8dd568c6b9d7f97f’;
$VAR3 = ‘CurrentUser’;
$VAR4 = bless( {
‘table’ => ‘Users’
}, ‘RT::CurrentUser’ );

and the second is:

[Wed Jan 5 21:51:29 2005] [debug]: $VAR1 = ‘_session_id’;
$VAR2 = ‘026f81fb6958910a8dd568c6b9d7f97f’;

Now, I just noticed that this setup was installed against perl 5.8.0, which
raises a red flag - I’m going to have it reinstalled against 5.8.3 and hope
this issue just goes away.

Steve

Jesse_Vincent · January 5, 2005, 10:07pm

At Wednesday 1/5/2005 04:20 PM, Jesse Vincent wrote:

That’s very odd. drop in code to YAML::Dump or Data::Dumper the session
to your logs just after it’s loaded and also in the page footer (When
everything should be done already)?

I dumped the session twice, at the start & end of autohandler. When I type
in user name & pwd and submit, the second dump shows the full user object
stored in the session:

Innnteresting. Have you guys made any autohandler changes?

[Wed Jan 5 21:50:48 2005] [debug]: $VAR1 = ‘CurrentUser’;
$VAR2 = bless( {
‘_Class’ => ‘RT::CurrentUser’,
‘_SB_Record_Primary_RecordCache_key’ => ‘Users:id=1265’,
‘table’ => ‘Users’,
‘values’ => {
‘creator’ => ‘1’,
‘comments’ => ‘’,
‘state’ => undef,
‘webencoding’ => undef,
‘password’ => ‘sksdfjw48wert34n’,
‘realname’ => ‘TURNER, STEPHEN’,

<etc, etc cut out>
           }, 'RT::CurrentUser' );
$VAR3 = ‘_session_id’;
$VAR4 = ‘026f81fb6958910a8dd568c6b9d7f97f’;

And right then, how does the session look on disk?

Now, I just noticed that this setup was installed against perl 5.8.0, which
raises a red flag - I’m going to have it reinstalled against 5.8.3 and hope
this issue just goes away.

nod if not, we can dig deeper.

Ruslan_U_Zakirov1 · January 6, 2005, 1:28pm

I saw similar behaviour once if autohandler does some output to user
before cookie work. May be you have some debug print commands in
autohandler?

Stephen Turner wrote:

Stephen_Turner · January 6, 2005, 2:42pm

At Wednesday 1/5/2005 05:07 PM, Jesse Vincent wrote:

Now, I just noticed that this setup was installed against perl 5.8.0,
which
raises a red flag - I’m going to have it reinstalled against 5.8.3 and
hope
this issue just goes away.

nod if not, we can dig deeper.

Thanks for your time - I’ll post back when we solve this in case anyone
else runs into it.

Steve