Issue #325 resolved

SessionFilter, when given the storageClass option, should instantiate the supplied class

Anonymous created an issue

The following code in sessionfilter.py (line 122) is problematic because it does not instantiate the user supplied class:

{{{ sess.sessionStorage = conf('sessionFilter.storageClass', None) if sess.sessionStorage is None: sess.sessionStorage = globals()storage + 'Storage' }}}

I have updated the above code as follows:

{{{ sess.sessionStorage = conf('sessionFilter.storageClass', None) if sess.sessionStorage is None: sess.sessionStorage = globals()storage + 'Storage' else: sess.sessionStorage = sess.sessionStorage() }}}

This allows the user to supply a class that SessionFilter instantiates and therefore provides proper access to the cherrypy module runtime configuration.

Reported by charles.scheffold@verizonwireless.com

Comments (5)

  1. Anonymous

    Please wait on this. My previous understanding of how SessionFilter works led me to believe that a single instance would not work for me, but I've since done more testing and now I'm not sure.

  2. Anonymous

    Ok, I am quite sure now that SessionFilter should instantiate a class and not just accept a single instance as a parameter. This is especially important if you are using threading and your backend is a database. You definitely want each thread to have its own instance rather than sharing one, just like the built-in classes.

    So I am still using the above fix in order to support my OracleStorage class (based on PostgreSQLStorage) for the backend.

  3. Log in to comment