Damjan wrote:
For example, consider an extreme case such as WSGI. Through a goal of
WSGI being portability it effectively ignores practically everything
that Apache has to offer. Thus although Apache offers support for
authentication and authorisation, a WSGI user would have to implement
this functionality themselves or use a third party WSGI component that
does it for them.
OTOH
WSGI auth middleware already supports more auth methods than apache2 itself.
A distinction needs to be made here. HTTP supports Basic and Digest
authentication mechanisms, both of which are in Apache by default. The
authentication mechanism though needs to be seen as distinct from the
auth provider, that is, who actually validates that a user is valid.
Apache 2.2 separates these two things with there being a pluggable auth
provider facility with backend implementations for such things as
passwd like files, dbm database, ldap and using mod_dbd various SQL
databases. Because it is pluggable it can be extended to support any
sort of auth provider implementation you want. It is even technically
possibly to write an auth provider which makes used of Python to
perform the check using some custom system, although mod_python itself
doesn't provide this yet, so you need to roll your own auth module to
do it.
Even as far as authentication mechanisms go, you aren't limited to just
those as the fact that you can provide a complete authentication and/or
authorisation handler means you can implement other as well. You might
for example build on top of SSL and use client certificates to control
access, or you could use HTTP forms based login and sessions. These
custom mechanisms could also use the auth provider plugin system so
that they aren't dependent on one particular user validation mechanism.
Now, when you say that WSGI already supports more auth methods than
Apache 2 itself, are you referring to how the login/authentication is
handled over HTTP, or how client validation is handled, ie., auth
providers.
I am not being critical here, asking more to build my knowledge of WSGI
and what capabilities it does have.
Similarly with other Apache features
such as URL rewriting, proxying, caching etc etc.
Well, not everybody can use Apache ... and again there's already WSGI
middleware that's more flexible than the Apache modules for most of the
features you mention.
It's not that I think mod_python doesn't have uses.. I just think it's not
practical to make python web applications targeted solely to mod_python.
For what you are doing that may not be practical, but in a lot of other
places it would be a more than reasonable way of going about it. To
clarify though, I am not talking about building something which is
completed implemented within the context of mod_python alone and not
even something that is written in Python exclusively. What I have been
talking about is using Apache as a whole as the platform.
Thus, taking authentication as an example, for basic forms of
authentication it is best to use the standard mod_auth and auth
provider facilities of Apache to do it. For more complicated mechanisms
such as using HTTP form, more customisation is usually required and
this might be implemented using Python under mod_python but could just
as well be implemented in mod_perl. A main thing to note though is that
if Apache authentication handlers are written properly, it can be used
to span not just mod_python but apply to static files served by Apache,
as well as handlers which serve up content using other languages
modules such as PHP, mod_perl.
This is where I said it can be more about integration rather than
writing pure Python code, because if you use Apache and mod_python
properly, you don't end having to write code within a monoculture
consisting of one implementation language as you are if you use WSGI.
Instead, you can pick and choose the modules and languages which make
the most sense as far as allowing you to implement something in the
easiest way possible given what you have and the environment you are
operating in
All I can say is that since this is a Python language list, that many
here will be here because they want to program specifically in Python
and nothing else. Others though may well see the bigger picture and the
realities of working with big systems, especially in a corporate
environment, where one doesn't have a choice but to deal with code
developed over time and in different languages with a result that most
of the time you are writing more glue and than actual application code.
Thus, in an ideal world you might be able to write in Python and
nothing else, but it isn't always an ideal world.
Graham
