On Nov 4, 2:27 pm, "Mark Ramm" <[EMAIL PROTECTED]> wrote:
> I'm very excited about this sprint because we have a number of new
> features in TG2 including a very nice new set of tools for
> Authentication and Authorization

Mark, if you are looking at authentication and authorisation, could I
entice you to do some forward thinking in respect of session
management in as much as making it compatible with Apache mod_session
module that will be in Apache 2.4 (now available in 2.3 development
trunk).

For details on mod_session see:

  http://httpd.apache.org/docs/trunk/mod/mod_session.html

What this module means is that Apache could handle session management.
This includes handling the process of redirecting to login pages and
interacting with the session store through its session database
provider mechanism. Apache can also handle authentication aspects
through its auth provider mechanism.

In mod_wsgi already support auth provider mechanisms and wouldn't be
much more effort to also support session database provider mechanism.
Thus, Python code could be provided to implement the session store.

What does this all mean. Well it means that Apache could provide the
bridge for SSO across multiple web applications, be they Python, or
some other language. Authentication could be handle by various Apache
modules or delegated to Python code. The session store could equally
be handled by various Apache modules or delegated to Python code.

Yes I know that most Python people don't care about Apache and think
that everything needs to be done in the WSGI application exclusively,
but would be nice to get some interoperability going here. I believe
in fact that WSGI itself could benefit from this, as at the moment I
don't believe there is really any standardised session management
framework which supports plugable components for authentication and
session database, such that they can be easily replaced where
necessary by different web stacks.

The simplicity of how mod_session uses HTTP_SESSION variable on input
to application to provide session information and a response header
for data to be stored back to the session database when request
complete fits quite well with WSGI way of thinking and if existing
solutions could be modified to support this way of doing things, it
would make it really quite easy to have a WSGI application to delegate
such responsibilities back to Apache to do it. Even if Apache not
used, the method of interfacing between session mechanism and the
application running within context of active session could be applied
internally to WSGI applications itself in a generic way, rather than
the various different ways that now seem to exist. Thus you could end
up with WSGI components for session management and also pluggable
components for session database using in memory, or external
databases.

I know this might not make much sense to you and I really need to
right some proof of concept examples for WSGI as to how this could all
work, but thought to mention it just to get you thinking about it.
There may well be stuff in WSGI space already doing this for all I
know and am sure you will tell me about it if that is the case. :-)

BTW, maybe this is something for pypefitters cabal.

Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" 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-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to