On Nov 4, 10:16 pm, Gustavo Narea <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Tuesday November 4, 2008 11:51:15 Graham Dumpleton wrote:
>
> > 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.
>
> Those authentication-related features are already supported by repoze.who,
> among many others.
>
> > 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.
>
> In fact, I think that should be handled in the WSGI context for the sake of
> interoperability.
>
> > 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. :-)
>
> I think we should not have such a functionality specific to one webserver,
> operating system, etc. If we're going to do it, I think we should do it in the
> WSGI context.
But doing it exclusively at the WSGI level is the problem and is
actually limiting Python web applications from being able to use
features already provided by web servers.
Having it done within a specific WSGI application instance means you
cannot readily do single sign in across distinct applications, whether
they be Python WSGI, PHP or something else, hosted at the same time in
a server such as Apache. The idea that one would somehow composite the
distinct WSGI applications together within the one process or sub
interpreter context will not work, as various Python WSGI applications
will not play nicely together or you can't have multiple instances
running together. You therefore often have no choice but to run them
in separate processes and at that point you need to be able to
delegate the single sign in to a higher level. Delegation to higher
level is also needed to bridge single sign on easily to web
applications in other languages.
I am also not suggesting that one be tying one self to Apache. When
one delves into how mod_session works, one will find that what it does
is no different to how a WSGI middleware can provide a service to a
nested WSGI application through passing information through the WSGI
environment dictionary and then getting back information via response
headers. What I suggesting is a standardisation on how that is done
which would so happen to work with mod_session, but which would also
work for WSGI middleware components providing the same sort of
functionality. That is session abilities could be provided by Python
WSGI component within standalone WSGI application, or because the
method of interaction is the same, delegated back up to Apache instead
so that single sign on across applications can be more easily
achieved. The intent being here that lower level application
components running within it would know or care whether sessions being
handled by Apache or by a Python based WSGI middleware component.
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
-~----------~----~----~----~------~----~------~--~---
