[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