I think the way to go is PythonOption now, then consider
PythonSessionOption later - I too do not like too many options and am not
sure that session handling is a core function.
Changing it later (if we decide to) should not be a big problem - it's
pretty easy to just spit our a wrning that
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.apa
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 environm
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*" directi
Nicolas Lehuen wrote:
+1 for PythonOption session_
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 we
Nick wrote:
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
Nicolas Lehuen wrote:
+1 for PythonOption session_
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
+1 for PythonOption session_
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 <[EMAIL PROTECTED]>:
> Jim Gallacher wrote:
> > Just so I'm *really* clear, do you mean
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. S
Hi Nick,
I must be really dense today, because I need yet more clarification.
Nick wrote:
Jim Gallacher wrote:
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 con
Jim Gallacher wrote:
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?
Yes, I'm sorry, I mean disable the session mechanism altogether. Some
admins ma
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:
So, any further thoughts / comments / objections to PythonSessionOpti
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:
I've created
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 i
I hope there will be some nice examples and documentation to go with
this new session package/implementation.
On Mon, 2005-06-13 at 08:53 -0400, Jim Gallacher wrote:
> David Fraser wrote:
> > Hi Nicolas, Jim
> >
> > PythonSessionCreate as suggested is nice for flexibility, but scary for
> > non-
Personally I go along with the PythonSessionOption because its syntax is
less session api dependent and more config file friendly.
Keep up the good work!
On Mon, 2005-06-13 at 19:21 -0400, Jim Gallacher wrote:
> i3 Technologies wrote:
> > I hope there will be some nice examples and documentation
i3 Technologies wrote:
I hope there will be some nice examples and documentation to go with
this new session package/implementation.
Yes, there will be. Hopefully session handling will be a little simpler
in version 3.2, which may also help.
Any opinion on the apache directive to use? Now is
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 packa
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
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
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
21 matches
Mail list logo
