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 -- http://mail.python.org/mailman/listinfo/python-list
