[Trac] Users and Sessions (long message)

Tue Oct 4 14:26:06 CDT 2005

I'm struggling with restrict_owners too. I've added a comment to ticket 
#222, let's hope someone who understand how this works comments on it.

As for 4), you only need to run "DELETE FROM session" on your Trac 
installation's database:

echo "DELETE FROM session;" | sqlite /var/lib/trac/db/trac.db

HTH,
Daniel Serodio

ECKHART.CURT wrote:

>OK Gang. I have some meat to chew on.
>
>Last Friday, I started a meandering trail that has led me to the sessions table.
>I’m looking at TRAC 0.8.4 and I’ve only mucked with my own local copy of the code, so no worries polluting the real code (yet).
>
>My goal was to add in code that provided a drop down list of team members to the appropriate fields of a ticket.
>
>I might add here that I have been a professional programmer for over 20 years and while I haven't done anything in Python before, I've already got a confidience enough of what's going on here to tweek around a bit.  I sourced the code that I was adding based on patches that I located while searching the main TRAC site that were associated with the current trunk. I was thinking that it would be independent enough so that I could have this feature without pulling a full upgrade to 0.9, but now I'm wondering if I may have made a bad decision. :-)
>
>I was trying to splice in the patches that provided a dropdown lists of team members when entering or changing a ticket.  I got everything running, but still no dropdown list.  Then I started digging around to see what was wrong.
>
>I came to this passage of code:
>
>-----------------------
>    def get_known_users(self, cnx=None): 
>        """ 
>        Generator that yields information about all known users, i.e. users that 
>        have logged in to this Trac environment and possibly set their name and 
>        email. 
> 
>        This function generates one tuple for every user, of the form 
>        (username, name, email) ordered alpha-numerically by username. 
>        """ 
>        if not cnx: 
>            cnx = self.get_db_cnx() 
>        cursor = cnx.cursor() 
>        cursor.execute("SELECT DISTINCT s.username, n.var_value, e.var_value " 
>                       "FROM session AS s " 
>                       " LEFT JOIN session AS n ON (n.sid IS NULL " 
>                       "  AND n.username=s.username AND n.var_name = 'name') " 
>                       " LEFT JOIN session AS e ON (e.sid IS NULL " 
>                       "  AND e.username=s.username AND e.var_name = 'email') " 
>                       "WHERE s.sid IS NULL ORDER BY s.username") 
>        for username,name,email in cursor: 
>            yield username, name, email 
>---------------------------
>
>I extracted the query shown above into a custom report and sure enough got an empty result set.  By dumping my session table, I see that 'sid' is never null, so this join will never produce a result.
>
>So now I come to you good folks.  Here are a few questions that might help to guide the discussion:
>
>1) Is session support broken in 0.8.4?  From what I see in my sessions table, I have a suspicion.
>
>2) Under what conditions should I see a row in the session table where sid is NULL?  I understand how the table is being used to store arbitrary variables associated with a user, so I don't think this is a stupid user (i.e. me) problem.
>
>3) I see many SID groupings that have nothing more than the mod_time and last_visit variables.  What's the point?
>
>4) Is there a mechanism to clean out the session table?  I tried storing a session and I made up my sid as 'ECKHART'.  I changed the way that I authenticated everyone and made it lose the domain prefix and now I get 'session belongs to another user' or some such wording and I can't retrieve the session.  How do I erase it?  On a large installation, this table would get incredibly polluted very fast if what I see is typical.
>
>5) What controls the generation of a new SID for a person?  I have extracted a little bit of the table so that you can see what I'm looking at.  Seems to me that the 'Username' column ought to be enough to tie everything together for a user.  Once someone is authenticated, simply grouping based on Username would tie everything to a logged in user.  Non authenticated users could all be lumped together as 'anonymous' or 'somebody' and we should just disable the 'settings' link until they log in.  Storing a persistant cookie would then be superflous; The log in credentials would provide everything needed to ID the user.  You could use a browser cookie to track the session, but you wouln't need to store it in the session table.
>
>Amy I missing the boat here?  I've been trying to get email notification of tickets going also with only minor success, and I suspect that the session table might be driving some of those problems too.
>
>BTW, I was going to make the jump to the 0.9 trunk until I read Christopher's memory leak announcement this morning! :-)
>
>I would be willing to give this area some attention if you all would want me to.  I've seen a bit of discussion lately about authenticating users and I think this would strengthen TRAC a bit if we got thise settled.
>
>Extract of Curt's session table follows...
>
>------------------------
>022b6da6b200bc45953e5bfa  	JOULLIAN.DEBBIE  	mod_time  	1124991974
>cf245995393217a269df728b 	JOULLIAN.DEBBIE 	mod_time 	1124826081
>cf245995393217a269df728b 	JOULLIAN.DEBBIE 	last_visit 	1124822785
>f0b76c4c86fb5e2144eab61e 	JOULLIAN.DEBBIE 	mod_time 	1124737563
>f0b76c4c86fb5e2144eab61e 	JOULLIAN.DEBBIE 	last_visit 	1124737563
>8b7c1c866d060b44d6a4af32 	JOULLIAN.DEBBIE 	mod_time 	1124461768
>8b7c1c866d060b44d6a4af32 	JOULLIAN.DEBBIE 	last_visit 	1124461768
>5e9d6fdc8eefadd00dd63c95 	JOULLIAN.DEBBIE 	mod_time 	1124379587
>5e9d6fdc8eefadd00dd63c95 	JOULLIAN.DEBBIE 	last_visit 	1124378016
>32a9721f8e1ff74a67d2b999 	JOULLIAN.DEBBIE 	mod_time 	1124369951
>32a9721f8e1ff74a67d2b999 	JOULLIAN.DEBBIE 	last_visit 	1124308158
>05678f91411f50b780278eef 	JOULLIAN.DEBBIE 	mod_time 	1124288232
>05678f91411f50b780278eef 	JOULLIAN.DEBBIE 	last_visit 	1124280876
>f60e2e00984e571bf9033aaf 	JOULLIAN.DEBBIE 	mod_time 	1124197038
>517d4431bf8d77a7ef13e331 	JOULLIAN.DEBBIE 	email 	joullian.debbie at leg.state.fl.us
>517d4431bf8d77a7ef13e331 	JOULLIAN.DEBBIE 	name 	Debbie Joullian
>517d4431bf8d77a7ef13e331 	JOULLIAN.DEBBIE 	mod_time 	1123854155
>------------------------
>
>Curt Eckhart
>The Florida Legislature
>Office of Legislative Information Technology Services
>Office : (850) 488-5340
> 
>"A successful tool is one that was used to do something undreamt of by its author." - Stephen C. Johnson
>  
>