[EMAIL PROTECTED] wrote:
> I think that's pretty unlikely. The Profile object I'm using is simply
> a SQLObject thingie - my sessions are 100% managed through
> cherrypy.session like so:
>
> class Root(controllers.RootController):
> '''The base class for CherryPy connectivity'''
>
> # These are the variables that get preserved across accesses
> variables = {'top20': tagCloud(), 'category': 'all', 'stories': [],
> 'profile': None,
> 'data': None, 'pageType': None, 'loggedin': False,
> 'TREND': 1, 'OVER': -1,
> 'errormessage': '', 'PAGELEN': 20, 'pagenum': 0}
>
> # kw argument here is passed in from a calling method
> def getSessionVariables(self, kw={}):
> '''Updates the Root object's variables with changes from the
> cherrypy.session collection'''
> self.variables.update(cherrypy.session)
>
> #clear the error message
> self.variables['errormessage'] = ''
> if 'page' in kw and int(kw['page']):
> self.variables['pagenum'] = int(kw['page'])-1
> self.variables['featured'] = featuredProfile()
> return self.variables
Your Root controller is not guaranteed to be session safe. Although
cherrypy does use multiple threads it does not spawn a new Root
controller per session. The above getSessionVariables method is
probably what is leaking session information, as it is modifying a
shared resource. If you do all of your work with a copy of
Root.variables that should fix it.
I'm not sure about the specifics of your project, but it looks like the
Root.variables attribute is storing user-specific information. Moving
all of your user-specific information to cherrypy.session and
storing/accessing everything from there should fix your problem.
-Adam
>
> @expose('trendi.templates.base')
> def default(self, *args, **kw):
> '''This method catches any pathnames that do not match a
> specific method'''
> s = self.getSessionVariables(kw)
> if not s['pageType']: return self.index()
>
> # ...
>
> return s
>
> @expose('trendi.templates.base')
> def doLogin(self, *args, **kw):
> s = self.getSessionVariables(kw)
> if self.require(kw, ['username', 'password']):
> p = Profile.select(AND(Profile.q.name==kw['username'],
>
> Profile.q.password==self.encrypt(kw['password'])))
> if p and len(list(p)) == 1:
> p = p[0]
> if p.blocked: return self.errormessage('Your account
> has been blocked')
> self.login(p)
> s['pageType'] = 'main'
> return s
> return self.loginFailed()
>
> def login(self, p):
> s = self.getSessionVariables()
> p.tallyVisit += 1
> p.lastVisit = DateTimeCol.now()
> s['profile'] = p
>
>
> However, I suspect my problem might have something to do with the port
> routing/configuration. Looking at the logs, all requests are going
> through port 8080 and the cherrypy server is using the same thread for
> all requests. When starting the server it tells me thread_pool = 10;
> everything looks pretty normal as far as I can tell (and I haven't done
> anything to the server config):
>
> 2006-11-02 14:36:41,948 cherrypy.msg INFO CONFIG: server.environment:
> development
> 2006-11-02 14:36:41,948 cherrypy.msg INFO CONFIG:
> server.log_to_screen: True
> 2006-11-02 14:36:41,948 cherrypy.msg INFO CONFIG: server.log_file:
> 2006-11-02 14:36:41,949 cherrypy.msg INFO CONFIG:
> server.log_tracebacks: True
> 2006-11-02 14:36:41,949 cherrypy.msg INFO CONFIG:
> server.log_request_headers: True
> 2006-11-02 14:36:41,949 cherrypy.msg INFO CONFIG:
> server.protocol_version: HTTP/1.0
> 2006-11-02 14:36:41,949 cherrypy.msg INFO CONFIG: server.socket_host:
> 2006-11-02 14:36:41,950 cherrypy.msg INFO CONFIG: server.socket_port:
> 8080
> 2006-11-02 14:36:41,950 cherrypy.msg INFO CONFIG: server.socket_file:
> 2006-11-02 14:36:41,950 cherrypy.msg INFO CONFIG: server.reverse_dns:
> False
> 2006-11-02 14:36:41,951 cherrypy.msg INFO CONFIG:
> server.socket_queue_size: 5
> 2006-11-02 14:36:41,951 cherrypy.msg INFO CONFIG: server.thread_pool:
> 10
> 2006-11-02 14:36:42,199 cherrypy.msg INFO HTTP: Serving HTTP on
> http://localhost:8080/
>
>
> Diez B. Roggisch wrote:
> > [EMAIL PROTECTED] schrieb:
> > > I've got an alpha site up (http://www.trendi.com:8080 - it exists
> > > parallel with an older version on PHP/Apache on the main port), and
> > > I've opened it in my browser to discover that someone else is already
> > > logged in on a different machine somewhere else, but they appear logged
> > > in on my machine as well.
> > >
> > > I'm using cherrpy.session according to the docs; I'm storing a
> > > 'profile' object in this dictionary which authenticates the session's
> > > profile.
> > >
> > > Why would multiple users on multiple machines share the same session?
> > >
> > > I'm baffled. My first guess is this is a configuration issue. Has
> > > anyone else seen this before? I apologize if you have, but I've been
> > > perusing several sites and can't find any incidents of this. Thanks in
> > > advance!
> >
> > Could it be for whatever reason that your profile-object has shared state?
> >
> > Diez
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
