[rt-users] Recurring signin with 3.6.4
Patterson, Craig
crpatter at ci.grand-rapids.mi.us
Thu Dec 6 13:24:03 EST 2007
Kenn,
I don't think it's a cookie issue. What we noticed was that the session
file on the server that the cookie referred to didn't have its
attributes filled in. So, I believe the problem is that sometimes the
session file fails to fully write. When we've looked at a file for a
session that didn't have the repeated login problem, it has the binary
data followed by attributes, ie, username, etc. When we looked at the
session file for when we did have the repeated login issue, it only has
binary data filled in.
What you can do to verify this is, first, look at the cookie of a
repeated login session to get its session id. Then look that at the
corresponding session file in the rthome/var/session folder.
I've attached an example of a good and a bad session file. They are
binary files, I looked at them with vi on linux and notepad in windows.
Craig Patterson
NGIT/City of Grand Rapids
-----Original Message-----
From: rt-users-bounces at lists.bestpractical.com
[mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Kenneth
Crocker
Sent: Thursday, December 06, 2007 12:45 PM
To: Joop van de Wege
Cc: rt Users
Subject: Re: [rt-users] Recurring signin with 3.6.4
Joop,
Thanks. We are currently doing the same thing you are (storing
session
on disk), yet I am still getting the two-time loop for sign-ins. What
did you do to resolve the cookie problem, if you had one? If you didn't
have a cookie problem, then I still can't figure out what is causing the
double sign-in. What were you're setup procedures/parameters for storing
session data to file? It perplexes me.
I was looking thru the archives and the causes seemed to be in
two
camps: 1) the DB camp - whereas an alter for the sessions table to
CLOB/ORACLE or LONGBLOB/MySQL seemed to work and 2) the store to file
camp - which listed various causes such as FireFox/cookies/expire date
on cookies/clearing cookies and possibly binary data corruption.
At this point, I feel the need to ask Jesse what your technical
guys
have found out about this problem in relation to ORACLE and/or FireFox?
Did this happen for ORACLE users in 3.6.1 thru 3.6.3? If not, what does
3.6.4 do differently that may cause this? This is critical to our
getting 3.6.4 into production. Any help here would be greatly
appreciated. Thanks.
Kenn
LBNL
On 12/6/2007 1:09 AM, Joop van de Wege wrote:
> Kenneth Crocker wrote:
>> Kenneth,
>>
>>
>> We are on Oracle 9 (soon going to 10) and RT doesn't seem to work
>> well with Oracle for sessions. So we use the "file" method for
>> storing. I would love to hear from anyone using Oracle on how they
>> deal with the sessions table problem.
>>
>> Kenn
>> LBNL
>>
>> On 12/5/2007 5:49 AM, Kenneth Marshall wrote:
>>> Craig and Kenn,
>>>
>>> I am curious. What are your reasons for storing the session
information
>>> in a file and not in the database?
>>>
> We tried it too, storing in the db, using Oracle XE (10g) but it
doesn't
> work somehow.
> Since storing on disk does work and having a cron entry removing
> everything older than a couple of days I don't mind being those files
on
> disk. There isn't any data in it which needs to be backuped up so I
let
> it be.
>
> Joop
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
> SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
>
> If you sign up for a new RT support contract before December 31, we'll
take
> up to 20 percent off the price. This sale won't last long, so get in
> touch today. Email us at sales at bestpractical.com or call us at +1
617
> 812 0745.
>
>
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy
> a copy at http://rtbook.bestpractical.com
>
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
If you sign up for a new RT support contract before December 31, we'll
take
up to 20 percent off the price. This sale won't last long, so get in
touch today.
Email us at sales at bestpractical.com or call us at +1 617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: sales at bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d960b271c4df5258f21681a8da6fdbc2.good
Type: application/octet-stream
Size: 3109 bytes
Desc: d960b271c4df5258f21681a8da6fdbc2.good
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20071206/4c596a42/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: d960b271c4df5258f21681a8da6fdbc2.bad
Type: application/octet-stream
Size: 197 bytes
Desc: d960b271c4df5258f21681a8da6fdbc2.bad
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20071206/4c596a42/attachment-0001.obj>
More information about the rt-users
mailing list