V3.6.1 / Logged out issues

I am running 3.6.1. I’m not using an LDAP overlay, just a basic config.
I seem to have issues where I am logged out (usually when creating or
resolving a ticket).

All the input when doing these things is still there, and when logging
back in I get taken right back to the ticket.

I am running Apache2 with fastcgi. Has there been a definitive answer
on this for those who are not using an LDAP authentication method?

Thanks,

Tony
For LAN Support:
http://www.myitdepartment.net/index.php?option=com_content&task=view&id=13&Itemid=29

For Internet Support:
http://www.cavalierbroadband.com/index.php?option=com_content&task=view&id=41&Itemid=30

I am running 3.6.1. I’m not using an LDAP overlay, just a basic config.
I seem to have issues where I am logged out (usually when creating or
resolving a ticket).

If you try 3.6.1 without your LDAP overlay, does the same thing happen?

Jesse Vincent jesse@bestpractical.com 08/15/06 05:25PM >>>

So. Is this a 3.6.1 with no local customizations whatsoever that's breaking? If so, the right next step is to turn on cookie notification in your browser and see if RT is sending a new cookie right before each forced relogin attempt. Also, it's worth stopping apache, clearing out rt's var/mason/obj directory, and starting apache again. It's possible for some things to get cached across server restarts. Yes, it is setting a cookie at the login again. What gives? Usually it is when a ticket is being reolved (with or without response to requestors, or when manually creating a new ticket and "saving it". All the input is saved, and it takes you right back to the same ticket.I did stop apache and clean the obj directory, and turned on firefox to prompt for all cookies. When i got kicked out to the login screen, it prompted me to set a cookie when I hit "Login". For LAN Support: http://www.myitdepartment.net/index.php?option=com_content&task=view&id=13&Itemid=29

For Internet Support:
http://www.cavalierbroadband.com/index.php?option=com_content&task=view&id=41&Itemid=30

Jesse Vincent jesse@bestpractical.com 08/15/06 05:25PM >>>

So. Is this a 3.6.1 with no local customizations whatsoever that's breaking? If so, the right next step is to turn on cookie notification in your browser and see if RT is sending a new cookie right before each forced relogin attempt. Also, it's worth stopping apache, clearing out rt's var/mason/obj directory, and starting apache again. It's possible for some things to get cached across server restarts. Yes, it is setting a cookie at the login again. What gives? Usually it is when a ticket is being reolved (with or without response to requestors, or when manually creating a new ticket and "saving it". All the input is saved, and it takes you right back to the same ticket.I did stop apache and clean the obj directory, and turned on firefox to prompt for all cookies. When i got kicked out to the login screen, it prompted me to set a cookie when I hit "Login".

That’s very strange and somewhat unexpected with 3.6.1.

Try enabling this option in your RT_Config:

$WebSessionClass is the class you wish to use for managing Sessions.

It defaults to use your SQL database, but if you are using MySQL 3.x

and

plans to use non-ascii Queue names, uncomment and add this line to

RT_SiteConfig.pm will prevent session corruption.

Set($WebSessionClass , ‘Apache::Session::File’);

I seem to be experiencing the same difficulty – same version of RT,
no customizations. The issue only occurs if I’m using SSL, however.
I activated the aforementioned configuration, but no change. The
following actions send me back to the log-in (and upon authenticating
I’m immediately directed to the proper page):

  • Take
  • Resolve
  • Open (from resolved)

Still poking around to see if I can make some sense of it.

-FCOn 8/18/06, Jesse Vincent jesse@bestpractical.com wrote:

On Fri, Aug 18, 2006 at 10:37:50AM -0400, Tony Graziano wrote:

Jesse Vincent jesse@bestpractical.com 08/15/06 05:25PM >>>
On Tue, Aug 15, 2006 at 04:58:07PM -0400, Tony Graziano wrote:

So. Is this a 3.6.1 with no local customizations whatsoever
that’s breaking? If so, the right next step is to turn on cookie
notification in your browser and see if RT is sending a new cookie
right
before each forced relogin attempt. Also, it’s worth stopping apache,
clearing
out rt’s var/mason/obj directory, and starting apache again. It’s
possible for some things to get cached across server restarts.

Yes, it is setting a cookie at the login again. What gives? Usually it
is when a ticket is being reolved (with or without response to
requestors, or when manually creating a new ticket and “saving it”. All
the input is saved, and it takes you right back to the same ticket.I did
stop apache and clean the obj directory, and turned on firefox to prompt
for all cookies. When i got kicked out to the login screen, it prompted
me to set a cookie when I hit “Login”.

That’s very strange and somewhat unexpected with 3.6.1.

Try enabling this option in your RT_Config:

$WebSessionClass is the class you wish to use for managing Sessions.

It defaults to use your SQL database, but if you are using MySQL 3.x

and

plans to use non-ascii Queue names, uncomment and add this line to

RT_SiteConfig.pm will prevent session corruption.

Set($WebSessionClass , ‘Apache::Session::File’);


For LAN Support:
http://www.myitdepartment.net/index.php?option=com_content&task=view&id=13&Itemid=29

For Internet Support:
http://www.cavalierbroadband.com/index.php?option=com_content&task=view&id=41&Itemid=30


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Also of potential interest – if I go back and re-submit the
resolve form, it behaves normally (takes me back to
Ticket/Update.html).

-FCOn 8/18/06, Frances Albemuth frances.cincinattus@gmail.com wrote:

I seem to be experiencing the same difficulty – same version of RT,
no customizations. The issue only occurs if I’m using SSL, however.
I activated the aforementioned configuration, but no change. The
following actions send me back to the log-in (and upon authenticating
I’m immediately directed to the proper page):

  • Take
  • Resolve
  • Open (from resolved)

Still poking around to see if I can make some sense of it.

-FC

On 8/18/06, Jesse Vincent jesse@bestpractical.com wrote:

On Fri, Aug 18, 2006 at 10:37:50AM -0400, Tony Graziano wrote:

Jesse Vincent jesse@bestpractical.com 08/15/06 05:25PM >>>
On Tue, Aug 15, 2006 at 04:58:07PM -0400, Tony Graziano wrote:

So. Is this a 3.6.1 with no local customizations whatsoever
that’s breaking? If so, the right next step is to turn on cookie
notification in your browser and see if RT is sending a new cookie
right
before each forced relogin attempt. Also, it’s worth stopping apache,
clearing
out rt’s var/mason/obj directory, and starting apache again. It’s
possible for some things to get cached across server restarts.

Yes, it is setting a cookie at the login again. What gives? Usually it
is when a ticket is being reolved (with or without response to
requestors, or when manually creating a new ticket and “saving it”. All
the input is saved, and it takes you right back to the same ticket.I did
stop apache and clean the obj directory, and turned on firefox to prompt
for all cookies. When i got kicked out to the login screen, it prompted
me to set a cookie when I hit “Login”.

That’s very strange and somewhat unexpected with 3.6.1.

Try enabling this option in your RT_Config:

$WebSessionClass is the class you wish to use for managing Sessions.

It defaults to use your SQL database, but if you are using MySQL 3.x

and

plans to use non-ascii Queue names, uncomment and add this line to

RT_SiteConfig.pm will prevent session corruption.

Set($WebSessionClass , ‘Apache::Session::File’);


For LAN Support:
http://www.myitdepartment.net/index.php?option=com_content&task=view&id=13&Itemid=29

For Internet Support:
http://www.cavalierbroadband.com/index.php?option=com_content&task=view&id=41&Itemid=30


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

The more I poke and prod the issue, the more I’m beginning to think
this is actually The Infinite Login Bug™. I’ve therefore attempted
most of the troubleshooting suggested in the infinite login thread,
but so far to no avail. The only thing that seems to separate my case
is the fact that it appears to work normally if I disable SSL.
Unfortunately, SSL is a necessity in environment. I’m keeping my
fingers crossed for suggestions…

Thanks,

-FCOn 8/18/06, Frances Albemuth frances.cincinattus@gmail.com wrote:

Also of potential interest – if I go back and re-submit the
resolve form, it behaves normally (takes me back to
Ticket/Update.html).

-FC

On 8/18/06, Frances Albemuth frances.cincinattus@gmail.com wrote:

I seem to be experiencing the same difficulty – same version of RT,
no customizations. The issue only occurs if I’m using SSL, however.
I activated the aforementioned configuration, but no change. The
following actions send me back to the log-in (and upon authenticating
I’m immediately directed to the proper page):

  • Take
  • Resolve
  • Open (from resolved)

Still poking around to see if I can make some sense of it.

-FC

On 8/18/06, Jesse Vincent jesse@bestpractical.com wrote:

On Fri, Aug 18, 2006 at 10:37:50AM -0400, Tony Graziano wrote:

Jesse Vincent jesse@bestpractical.com 08/15/06 05:25PM >>>
On Tue, Aug 15, 2006 at 04:58:07PM -0400, Tony Graziano wrote:

So. Is this a 3.6.1 with no local customizations whatsoever
that’s breaking? If so, the right next step is to turn on cookie
notification in your browser and see if RT is sending a new cookie
right
before each forced relogin attempt. Also, it’s worth stopping apache,
clearing
out rt’s var/mason/obj directory, and starting apache again. It’s
possible for some things to get cached across server restarts.

Yes, it is setting a cookie at the login again. What gives? Usually it
is when a ticket is being reolved (with or without response to
requestors, or when manually creating a new ticket and “saving it”. All
the input is saved, and it takes you right back to the same ticket.I did
stop apache and clean the obj directory, and turned on firefox to prompt
for all cookies. When i got kicked out to the login screen, it prompted
me to set a cookie when I hit “Login”.

That’s very strange and somewhat unexpected with 3.6.1.

Try enabling this option in your RT_Config:

$WebSessionClass is the class you wish to use for managing Sessions.

It defaults to use your SQL database, but if you are using MySQL 3.x

and

plans to use non-ascii Queue names, uncomment and add this line to

RT_SiteConfig.pm will prevent session corruption.

Set($WebSessionClass , ‘Apache::Session::File’);


For LAN Support:
http://www.myitdepartment.net/index.php?option=com_content&task=view&id=13&Itemid=29

For Internet Support:
http://www.cavalierbroadband.com/index.php?option=com_content&task=view&id=41&Itemid=30


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

The more I poke and prod the issue, the more I’m beginning to think
this is actually The Infinite Login Bug™. I’ve therefore attempted
most of the troubleshooting suggested in the infinite login thread,
but so far to no avail. The only thing that seems to separate my case
is the fact that it appears to work normally if I disable SSL.
Unfortunately, SSL is a necessity in environment. I’m keeping my
fingers crossed for suggestions…

Can you tell us about what RT is doing differently with cookies acorss
your secure and insecure sites?

Alright, so I checked into this per your advice, and here’s what
happened. I recorded the current cookies, moved everything back to
unsecured HTTP, dumped the mason cache, restarted httpd, cleared my
cookies, tried to duplicate the problem. Well, the problem was
notably worse - every click led to the log in screen. I figured
Apache::Session might be confused after all of this, so I tried to
logout via the web UI (to dump my session). I received this error:

error: Could not remove file: Permission denied at
/usr/lib/perl5/site_perl/5.8.5/Apache/Session/Store/File.pm line 106.
context:

102: $self->{opened} = 0;
103: }
104:
105: if (-e $directory.‘/’.$session->{data}->{_session_id}) {
106: unlink ($directory.‘/’.$session->{data}->{_session_id}) ||
107: die “Could not remove file: $!”;
108: }
109: else {
110: die “Object does not exist in the data store”;

code stack: /usr/lib/perl5/site_perl/5.8.5/Apache/Session/Store/File.pm:106
/usr/lib/perl5/site_perl/5.8.5/Apache/Session.pm:515o
/usr/lib/perl5/site_perl/5.8.5/Apache/Session/File.pm:40
/usr/lib/perl5/site_perl/5.8.5/HTML/Mason/Request.pm:1249

So, I reverted everything back to secured http (because it was an
easy thing to try), and the problem persisted. I tracked down a
couple of files in /tmp that were owned by the apache user, dumped
those along with /tmp/fcgi, dumped the mason cache, dumped my cookies
again, and restarted httpd. So far, I’ve been unable to duplicate the
problem. It’s likely that somewhere in all this there was human error
on my part. I’m fairly certain (though I don’t recall trying to
logout before – bad habits and all) that this error didn’t occur
until I jostled everything around in hopes of figuring out what was
different about the cookies being handed out. One thing of note: I
initially noticed (using SSL) that I was receiving a number of
cookies; one for rt..443, one for rt..80, and a couple relating to
specific pages (Quick Search, et al). Afterwards, I received a single
cookie for rt.*.443. Let me know if there’s anything else I should
investigate that I might shed light or provide useful data (if indeed
this has anything to do with the infinite login issue).

Thanks,

-FCOn 8/23/06, Jesse Vincent jesse@bestpractical.com wrote:

On Wed, Aug 23, 2006 at 11:14:08AM -0700, Frances Albemuth wrote:

The more I poke and prod the issue, the more I’m beginning to think
this is actually The Infinite Login Bug™. I’ve therefore attempted
most of the troubleshooting suggested in the infinite login thread,
but so far to no avail. The only thing that seems to separate my case
is the fact that it appears to work normally if I disable SSL.
Unfortunately, SSL is a necessity in environment. I’m keeping my
fingers crossed for suggestions…

Can you tell us about what RT is doing differently with cookies acorss
your secure and insecure sites?

error: Could not remove file: Permission denied at
/usr/lib/perl5/site_perl/5.8.5/Apache/Session/Store/File.pm line 106.
context:

I have seen this ‘Permission denied’ error with 3.6.0. I fixed it by
replacing existing web related entries in RT_SiteConfig.pm with the
ones from RT_Config.pm and editing the entries as required. There
was a new entry added but I do not remember which one. I did not see
the error anymore. I use https and have not tried http.

Alex

In my case, this appears to have been caused by SELinux not allowing
Apache to manipulate objects in /tmp. Everything is resolved to the
best my knowledge at this time. I would advise users working with RT
3.6.1 experiencing session issues to validate that their SELinux rules
aren’t interfering. The quick and dirty way to validate this is to
tell SELinux not to enforce rules:

(Under RHEL and derivatives)

echo “0” >/selinux/enforcing

Try to reproduce the symptom. If you still have the problem at this
point, it’s probably not SELinux. Of course, flip it back to one when
you’re finished.

-FCOn 8/24/06, Alex Moore asmoore@edge.net wrote:

On Wed, 23 Aug 2006 18:51:54 -0700 “Frances Albemuth” frances.cincinattus@gmail.com wrote:

error: Could not remove file: Permission denied at
/usr/lib/perl5/site_perl/5.8.5/Apache/Session/Store/File.pm line 106.
context:

I have seen this ‘Permission denied’ error with 3.6.0. I fixed it by
replacing existing web related entries in RT_SiteConfig.pm with the
ones from RT_Config.pm and editing the entries as required. There
was a new entry added but I do not remember which one. I did not see
the error anymore. I use https and have not tried http.

Alex