|
Home > Archive > Apache Mod-Python > June 2005 > PythonSessionOption - a new apache directive for session configuration
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
PythonSessionOption - a new apache directive for session configuration
|
|
| Jim Gallacher 2005-06-12, 5:46 pm |
| I've created a new apache directive called PythonSessionOption. This
would be used to configure session handling in the apache config file.
This data is accessed with a new request method, req.get_session_options().
Although we could use the PythonOption directive instead of creating a
new one, I believe it's better to keep the session config data separate
so we don't need to worry about collisions with current user code or
configuration.
Typical Usage
-------------
In a test script mptest.py
def handler(req)
opts = req.get_session_options()
for k in sess_conf:
req.write('%s: %s' % (k,opts[k])
In Session.FileSession:
__init__(self,req,sid):
opts = req.get_session_options()
timeout = int(opts.get('timeout', DFT_TIMEOUT))
In an Apache config file:
<VirtualHost 192.168.1.12:80>
ServerAdmin webmaster@localhost
ServerName example.com
DocumentRoot /var/www/
PythonSessionOption session FileSession
PythonSessionOption session_directory /var/lib/mod_python/sess
PythonSessionOption timeout 14400
PythonSessionOption lock 1
...
</VirtualHost>
If there are no objections I'll commit the code. I have not refactored
Sessions.py to use the new configuration scheme just yet.
Regards,
Jim
| |
| Nicolas Lehuen 2005-06-13, 2:45 am |
| Hi Jim,
Why not have a single 'PythonSessionCreate' option which contains the
line of code that should be evaled to create the session ?
Example :
PythonSessionCreate
"Session.FileSession(session_directory=3D'/var/lib/mod_python/sess',timeout=
=3D14400,lock=3D1)"
The cost of eval could be brought down by precompiling the option
string to a code object and running the code object in precompiled
form.
This seems a bit more flexible to me and won't force you to refactor
the Session.py code.
Regards,
Nicolas
2005/6/12, Jim Gallacher <jg.lists@sympatico.ca>:
> I've created a new apache directive called PythonSessionOption. This
> would be used to configure session handling in the apache config file.
> This data is accessed with a new request method, req.get_session_options(=
).
>=20
> Although we could use the PythonOption directive instead of creating a
> new one, I believe it's better to keep the session config data separate
> so we don't need to worry about collisions with current user code or
> configuration.
>=20
> Typical Usage
> -------------
>=20
> In a test script mptest.py
>=20
> def handler(req)
> opts =3D req.get_session_options()
> for k in sess_conf:
> req.write('%s: %s' % (k,opts[k])
>=20
> In Session.FileSession:
> __init__(self,req,sid):
> opts =3D req.get_session_options()
> timeout =3D int(opts.get('timeout', DFT_TIMEOUT))
>=20
> In an Apache config file:
>=20
> <VirtualHost 192.168.1.12:80>
> ServerAdmin webmaster@localhost
> ServerName example.com
> DocumentRoot /var/www/
>=20
> PythonSessionOption session FileSession
> PythonSessionOption session_directory /var/lib/mod_python/sess
>=20
> PythonSessionOption timeout 14400
> PythonSessionOption lock 1
>=20
> ...
> </VirtualHost>
>=20
> If there are no objections I'll commit the code. I have not refactored
> Sessions.py to use the new configuration scheme just yet.
>=20
> Regards,
> Jim
>
| |
| David Fraser 2005-06-13, 7:46 am |
| Hi Nicolas, Jim
PythonSessionCreate as suggested is nice for flexibility, but scary for
non-coders - I like Jim's multiple options for that reason
David
Nicolas Lehuen wrote:
>Hi Jim,
>
>Why not have a single 'PythonSessionCreate' option which contains the
>line of code that should be evaled to create the session ?
>
>Example :
>
>PythonSessionCreate
>"Session.FileSession(session_directory='/var/lib/mod_python/sess',timeout=14400,lock=1)"
>
>The cost of eval could be brought down by precompiling the option
>string to a code object and running the code object in precompiled
>form.
>
>This seems a bit more flexible to me and won't force you to refactor
>the Session.py code.
>
>Regards,
>Nicolas
>
>2005/6/12, Jim Gallacher <jg.lists@sympatico.ca>:
>
>
>
>
>
| |
| Jim Gallacher 2005-06-13, 7:46 am |
| David Fraser wrote:
> Hi Nicolas, Jim
>
> PythonSessionCreate as suggested is nice for flexibility, but scary for
> non-coders - I like Jim's multiple options for that reason
I would argue that PythonSessionCreate is less flexible for users and
admins. It requires a knowledge of the mod_python package structure
(Session.FileSession), which will then get hard coded into the apache
configuration files. If we decide in the future to split the Session
classes into separate files, we'll break all existing configurations.
PythonSessionOption will likely only be used to override the existing
defaults defined in the code, so most configs will look like this:
PythonSessionOption session DbmSession
PythonSessionOption timeout 28800
I'll grant you that the config file will become cluttered with a larger
number of PythonSessionOption directives for more a complicated setup,
but the same problem exists for PythonSessionCreate. eg.
PythonSessionCreate
"Session.FileSession(session_directory='/var/lib/mod_python/ sess',timeout=14400,secret='howdy',lock=
1,fast_cleanup=1,verify_cleanup=1,gracep
eriod=20,this_string_is_hard_read=True)"
Using Python code in the config file means the admin needs to worry
about proper quoting of the string. We should not assume that the admin
will be a programmer. I can imagine the mailing list questions, and
Graham already spends enough time answering questions. 
I also think that parsing the PythonSessionCreate string will turn out
to be a difficult task to do in a really robust way.
And the real reason for using PythonSessionOptions? Through the magic of
cut and paste programming I was able to adapt PythonOptions/get_options
in about 5 minutes with high confidence it would work the first time. It
did.
As far as refactoring Session.py, I've already done this to some extent
in my attempts to track down the memory leak with the req_get_session()
method - not a big job. Most of the config handling code would be added
to BaseSession.__init__(). My personal preference if we refactor
Session.py is to go all the way and split it into a package right now.
We are making enough changes in the way sessions are used that I think
it is the correct time, rather than half now and half later.
mod_python.session2 anyone? Session.py becomes wrapper around the new
package structure for backwards compatability, and coders using release
>= 3.2.0 will use the PythonSessionOption, req.get_session() combo for
their new code.
Regards,
Jim
> David
>
> Nicolas Lehuen wrote:
>
>
| |
| Jim Gallacher 2005-06-15, 5:48 pm |
| So, any further thoughts / comments / objections to PythonSessionOption,
or shall I just check in the code?
Regards
Jim
Jim Gallacher wrote:
> I've created a new apache directive called PythonSessionOption. This
> would be used to configure session handling in the apache config file.
> This data is accessed with a new request method, req.get_session_options().
>
> Although we could use the PythonOption directive instead of creating a
> new one, I believe it's better to keep the session config data separate
> so we don't need to worry about collisions with current user code or
> configuration.
>
> Typical Usage
> -------------
>
> In a test script mptest.py
>
> def handler(req)
> opts = req.get_session_options()
> for k in sess_conf:
> req.write('%s: %s' % (k,opts[k])
>
>
> In Session.FileSession:
> __init__(self,req,sid):
> opts = req.get_session_options()
> timeout = int(opts.get('timeout', DFT_TIMEOUT))
>
>
> In an Apache config file:
>
> <VirtualHost 192.168.1.12:80>
> ServerAdmin webmaster@localhost
> ServerName example.com
> DocumentRoot /var/www/
>
> PythonSessionOption session FileSession
> PythonSessionOption session_directory /var/lib/mod_python/sess
> PythonSessionOption timeout 14400
> PythonSessionOption lock 1
>
> ...
> </VirtualHost>
>
> If there are no objections I'll commit the code. I have not refactored
> Sessions.py to use the new configuration scheme just yet.
>
> Regards,
> Jim
>
| |
|
| How about an explicit "None" value to completely disable it? If you don't
want users on your site using it.
Nick
Jim Gallacher wrote:
> So, any further thoughts / comments / objections to PythonSessionOption,
> or shall I just check in the code?
>
> Regards
> Jim
>
>
> Jim Gallacher wrote:
>
>
>
| |
| Nicolas Lehuen 2005-06-15, 5:48 pm |
| Jim, just one question. Suppose I write a home-made session
implementation, myownsessionmodule.MyOwnSession. How would I configure
this using PythonSessionOption ? I see there is no problem for
paramaters (the different session classes use whatever session
parameter they need), but will I be able to write this :
PythonSessionOption session myownsessionmodule.MyOwnSession
That is to say, are you using this parameter as the class name, in
which case your example should be :
PythonSessionOption session Session.FileSession
and not=20
PythonSessionOption session FileSession
Or are you looking for the class in the Session module, thus
forbidding other implementations to step in ?
Regards,
Nicolas
2005/6/15, Jim Gallacher <jg.lists@sympatico.ca>:
> So, any further thoughts / comments / objections to PythonSessionOption,
> or shall I just check in the code?
>=20
> Regards
> Jim
>=20
>=20
> Jim Gallacher wrote:
s().[vbcol=seagreen]
>=20
>
| |
| Jim Gallacher 2005-06-15, 5:48 pm |
| Nicolas Lehuen wrote:
> Jim, just one question. Suppose I write a home-made session
> implementation, myownsessionmodule.MyOwnSession. How would I configure
> this using PythonSessionOption ? I see there is no problem for
> paramaters (the different session classes use whatever session
> parameter they need), but will I be able to write this :
>
> PythonSessionOption session myownsessionmodule.MyOwnSession
Currently, for testing purposes req.get_session() calls
mod_python.Session.create_session() which looks like this:
Session.py
----------
def create_session(req,sid):
opts = req.get_session_options()
session_type = opts['session']
if session_type == 'FileSession':
return FileSession(req,sid)
elif session_type == 'DbmSession':
return DbmSession(req,sid)
... and so on
Not pretty but it works.
> That is to say, are you using this parameter as the class name, in
> which case your example should be :
> PythonSessionOption session Session.FileSession
>
> and not
>
> PythonSessionOption session FileSession
>
> Or are you looking for the class in the Session module, thus
> forbidding other implementations to step in ?
As create_session() is currently implemented only known sessions classes
are allowed, but it should be easy to change it to load a module
instead. Python is a dynamic language after all.
Regards,
Jim
> Regards,
> Nicolas
>
>
> 2005/6/15, Jim Gallacher <jg.lists@sympatico.ca>:
>
>
| |
| Nicolas Lehuen 2005-06-15, 5:48 pm |
| OK then I'm OK if you check your code. We'll fix this later, and
anyway if someone has a custom session implementation, he is already
using it wihout get_session() so there won't be any regression of his
code.
Regards,
Nicolas
2005/6/15, Jim Gallacher <jg.lists@sympatico.ca>:
> Nicolas Lehuen wrote:
>=20
> Currently, for testing purposes req.get_session() calls
> mod_python.Session.create_session() which looks like this:
>=20
> Session.py
> ----------
>=20
> def create_session(req,sid):
> opts =3D req.get_session_options()
> session_type =3D opts['session']
> if session_type =3D=3D 'FileSession':
> return FileSession(req,sid)
> elif session_type =3D=3D 'DbmSession':
> return DbmSession(req,sid)
>=20
> ... and so on
>=20
> Not pretty but it works.
>=20
>=20
> As create_session() is currently implemented only known sessions classes
> are allowed, but it should be easy to change it to load a module
> instead. Python is a dynamic language after all.
>=20
> Regards,
> Jim
>=20
,[vbcol=seagreen]
ns().[vbcol=seagreen]
e[vbcol=seagreen]
>=20
>
| |
| Jim Gallacher 2005-06-15, 5:48 pm |
| Nick wrote:
> How about an explicit "None" value to completely disable it? If you
> don't want users on your site using it.
Do you mean to disable sessions, or just the session configuration?
Jim
> Nick
>
> Jim Gallacher wrote:
>
>
| |
|
| Jim Gallacher wrote:
> Nick wrote:
>
>
> Do you mean to disable sessions, or just the session configuration?
Yes, I'm sorry, I mean disable the session mechanism altogether. Some
admins may see it as a potential security issue. Although I'm sure you're
doing the best you can to make sure it can't be exploited as such, if you
make it so people can evenutally plug in their own session mechanisms, there
might be room for abuse.
Nick
| |
| Jim Gallacher 2005-06-15, 5:48 pm |
| Hi Nick,
I must be really dense today, because I need yet more clarification.
Nick wrote:
> Jim Gallacher wrote:
>
>
>
> Yes, I'm sorry, I mean disable the session mechanism altogether. Some
> admins may see it as a potential security issue. Although I'm sure
> you're doing the best you can to make sure it can't be exploited as
> such, if you make it so people can evenutally plug in their own session
> mechanisms, there might be room for abuse.
>
> Nick
>
Just so I'm *really* clear, do you mean the current scheme for session
handling would also be disabled? For example users would need to catch
an exception if the admin has disabled sessions:
def handler(req):
try:
sess = Session.Session(req)
except SecurityException:
req.log_error('sessions are disabled')
Or do you mean that using a config option like:
PythonSessionOption session mymodule.MySessionThing
would not be allowed if mymodule.MySessionThing was not in a list of
approved session classes?
I really don't see how sessions could be completely disabled, since all
you are really doing is setting a cookie and reading/writing some data
to a file.
Regards,
Jim
| |
|
| Jim Gallacher wrote:
> Just so I'm *really* clear, do you mean the current scheme for session
> handling would also be disabled?
The more I think about it, you're right; you can just set up the session
stuff without directives just the same by importing mod_python.Session and
going from there. So that line of reasoning has no merit.
I was confused by the adding of a new directive, which seems to indicate
that there would be some "default" Session handler being loaded if you
didn't specify one using the directive. Because in the old scheme there
wasn't really any "default" session handling, unless you outright imported
the libary and started using it. If it's going to work exactly the same way
as it did before, except now you can configure some defaults in the apache
config, then I'm probably worried over nothing. But it probably should have
an option for "None" or "disabled," which would be the default, meaning I
don't care to use the supplied session handlers, even though it didn't
really do anything extra than it does now.
But in that case, why not use "PythonOption session_<config_var> <value>",
which is probably what you were asking about in the first place, which I
think someone else mentioned as well. That doesn't imply that there is some
kind of default session handling, just the standard way of passing values
from the apache config to Python code. If the plan is to implement a pure C
session handler, then PythonSessionOption makes sense, but otherwise it
doesn't seem necessary.
Nick
| |
| Nicolas Lehuen 2005-06-15, 5:48 pm |
| +1 for PythonOption session_<variable> <value>
Unless choosing a specificc configuration directive has something to
do with security (i.e. no overloading of the settings in .htaccess
files) ?
Regards,
Nicolas
2005/6/15, Nick <nick@dd.revealed.net>:
> Jim Gallacher wrote:
>=20
> The more I think about it, you're right; you can just set up the session
> stuff without directives just the same by importing mod_python.Session an=
d
> going from there. So that line of reasoning has no merit.
>=20
> I was confused by the adding of a new directive, which seems to indicate
> that there would be some "default" Session handler being loaded if you
> didn't specify one using the directive. Because in the old scheme there
> wasn't really any "default" session handling, unless you outright importe=
d
> the libary and started using it. If it's going to work exactly the same =
way
> as it did before, except now you can configure some defaults in the apach=
e
> config, then I'm probably worried over nothing. But it probably should h=
ave
> an option for "None" or "disabled," which would be the default, meaning I
> don't care to use the supplied session handlers, even though it didn't
> really do anything extra than it does now.
>=20
> But in that case, why not use "PythonOption session_<config_var> <value>"=
,
> which is probably what you were asking about in the first place, which I
> think someone else mentioned as well. That doesn't imply that there is s=
ome
> kind of default session handling, just the standard way of passing values
> from the apache config to Python code. If the plan is to implement a pur=
e C
> session handler, then PythonSessionOption makes sense, but otherwise it
> doesn't seem necessary.
>=20
> Nick
>
| |
|
| Nicolas Lehuen wrote:
> +1 for PythonOption session_<variable> <value>
>
> Unless choosing a specificc configuration directive has something to
> do with security (i.e. no overloading of the settings in .htaccess
> files) ?
(This is what I was ineptly trying to get at earlier.)
Nick
| |
| Jim Gallacher 2005-06-15, 5:48 pm |
| Nick wrote:
> Jim Gallacher wrote:
>
>
>
> The more I think about it, you're right; you can just set up the session
> stuff without directives just the same by importing mod_python.Session
> and going from there. So that line of reasoning has no merit.
>
> I was confused by the adding of a new directive, which seems to indicate
> that there would be some "default" Session handler being loaded if you
> didn't specify one using the directive.
In the new scheme, a session is created when the user calls
req.get_session(). The parameters used for creating this session are
specified in the apache config file. Contrast this with the current
mechanism where a new session is created when the user calls
Session.Session(), and the parameters are for the session must be passed
in the session initalization.
eg.
New way:
sess = req.get_session()
Old way:
sess = Session.FileSession(req,timeout=100,
session_directory='/tmp/sess')
With the new way, the first call to req.get_session() returns a new
session instance (loads one from the persistent store). Subsequent calls
within the same request will return the *same* instance. Users no longer
need to worry about session lock management, and our deadlock issues
disappear. Using sessions will be much more transparent. Sticking the
session parameters in the apache configuration keeps the get_session()
call simple, and easily accomodates future changes to the underlying
session code.
> Because in the old scheme there
> wasn't really any "default" session handling, unless you outright
> imported the libary and started using it. If it's going to work exactly
> the same way as it did before, except now you can configure some
> defaults in the apache config, then I'm probably worried over nothing.
> But it probably should have an option for "None" or "disabled," which
> would be the default, meaning I don't care to use the supplied session
> handlers, even though it didn't really do anything extra than it does now.
Indeed, as long as you don't call req.get_session(), there will be no
session created. You may be thinking that every request automatically
creates a session object. This is emphatically not the case. This would
be a performance killer.
> But in that case, why not use "PythonOption session_<config_var>
> <value>", which is probably what you were asking about in the first
> place, which I think someone else mentioned as well. That doesn't imply
> that there is some kind of default session handling, just the standard
> way of passing values from the apache config to Python code.
I hope that the PythonSessionOption just makes it really obvious that
this directive is for session configuration. And certainly the lack of a
"PythonSessionOption session some_session_class" line in the apache
config tells the admin that there is no default session. The question
then becomes, if the above directive is missing should req.get_session()
still return some platform dependent session (just as Session.Session()
currently does), or should it raise an exception?
> If the
> plan is to implement a pure C session handler,
No immediate plans, but I have thought of it. I've actually been doing
some benchmarking on a SQL backend as well. This is of course completely
off topic.
> then PythonSessionOption
> makes sense, but otherwise it doesn't seem necessary.
My motivation for creating the new PythonSessionOption directive rather
than using the PythonOption is as follows:
1. Avoid breaking exisiting code. It's impossible to predict how people
may be currently using PythonOption. I feel it's better to leave current
configurations untouched to completely avoid possible keyword
collisions. This is the *big* one for me.
2. Avoid breaking exisiting code, in case anyone missed point 1.
3. Easier to document and explain. Or maybe I'm actually making things
more confusing?
Maybe I need to write some docs with a tutorial before checking in the
code so people have a better idea what the heck I'm doing? I'm not
trying to force this directive on anyone - just trying to make session
handling better and it seems like a nice complement to the new
request.get_session() method.
Regards,
Jim
| |
| Jim Gallacher 2005-06-15, 5:48 pm |
| Nicolas Lehuen wrote:
> +1 for PythonOption session_<variable> <value>
>
> Unless choosing a specificc configuration directive has something to
> do with security (i.e. no overloading of the settings in .htaccess
> files) ?
Not currently - it's just a cut and paste of directive_PythonOption
after all. However, a few weeks ago when we first discussed
req_get_session, one of the motivations was to give the apache server
admin more control over the session handling. So maybe we do need to
look at this from security perspective?
Jim
> Regards,
> Nicolas
>
> 2005/6/15, Nick <nick@dd.revealed.net>:
>
>
>
| |
| Nicolas Lehuen 2005-06-16, 7:45 am |
| Is there a way to forbid PythonSessionOption from appearing in a
..htaccess file ? If not, then there is no advantage (security-wise) in
having a different configuration directive.
But your point about not breaking existing code is a good one. If
someone already uses "PythonOption session*" directives to store some
configuration data, we will step on his feet. Of course, this
hypothetical guy will not use req.get_session() so there should not be
any problem... No, really, I don't think PythonSessionOption is
required.
Regards,
Nicolas
2005/6/15, Jim Gallacher <jg.lists@sympatico.ca>:
> Nicolas Lehuen wrote:
>=20
> Not currently - it's just a cut and paste of directive_PythonOption
> after all. However, a few weeks ago when we first discussed
> req_get_session, one of the motivations was to give the apache server
> admin more control over the session handling. So maybe we do need to
> look at this from security perspective?
>=20
> Jim
>=20
>=20
n[vbcol=seagreen]
and[vbcol=seagreen]
e[vbcol=seagreen]
e[vbcol=seagreen]
ted[vbcol=seagreen]
e way[vbcol=seagreen]
che[vbcol=seagreen]
have[vbcol=seagreen]
I[vbcol=seagreen]
>",
I[vbcol=seagreen]
some[vbcol=seagreen]
es[vbcol=seagreen]
ure C[vbcol=seagreen]
>=20
>
| |
| Jim Gallacher 2005-06-16, 7:45 am |
| Nicolas Lehuen wrote:
> Is there a way to forbid PythonSessionOption from appearing in a
> .htaccess file ?
I don't know. Is there a way to restrict the use of any Python*
directives? Or to restrict the use of AddHandler mod_python? These
restrictions would be useful in a shared hosting environment in general.
This might be something to persue, but if we want to release 3.2 before,
say Christmas... ;)
> If not, then there is no advantage (security-wise) in
> having a different configuration directive.
>
> But your point about not breaking existing code is a good one. If
> someone already uses "PythonOption session*" directives to store some
> configuration data, we will step on his feet. Of course, this
> hypothetical guy will not use req.get_session() so there should not be
> any problem... No, really, I don't think PythonSessionOption is
> required.
And there is an argument to be made for avoiding code bloat. So
PythonOption session_* it is then.
Regards,
Jim
> Regards,
> Nicolas
>
> 2005/6/15, Jim Gallacher <jg.lists@sympatico.ca>:
>
>
| |
| Jim Gallacher 2005-06-24, 5:46 pm |
| Nicolas Lehuen wrote:
> Is there a way to forbid PythonSessionOption from appearing in a
> .htaccess file ? If not, then there is no advantage (security-wise) in
> having a different configuration directive.
>
I know we've decided on using PythonOption session_* instead, but
looking at http://www.apachetutor.org/dev/config under the "Scope of
Configuration" it looks like it may not be that hard to restrict the use
of PythonSessionOption in a .htaccess file.
Is it worth persuing? Now is the time to do it. If we change it later it
means everyone will need to refactor their config files and any
subclasses of BaseSession.
Regards,
Jim
| |
|
| My feelings are 2-fold:
1. I don't think session management is strictly part of mod_python as an
apache handler, but rather as a utility module that can be used in
conjunction with it. In that sense, I don't think it needs its own directive.
2. I'd rather see more time spent on outstanding release issues
Nick
Jim Gallacher wrote:
> Nicolas Lehuen wrote:
>
>
> I know we've decided on using PythonOption session_* instead, but
> looking at http://www.apachetutor.org/dev/config under the "Scope of
> Configuration" it looks like it may not be that hard to restrict the use
> of PythonSessionOption in a .htaccess file.
>
> Is it worth persuing? Now is the time to do it. If we change it later it
> means everyone will need to refactor their config files and any
> subclasses of BaseSession.
>
> Regards,
> Jim
|
|
|
|
|