|
Graham Dumpleton
grahamd at dscpl.com.au
Sat May 21 05:53:15 EDT 2005
Some questions for you about this.
How does this information fit into the larger scheme of what you are
trying to do? Are you trying to separate this out into a separate
handler phase so that you don't have to duplicate that code in every
mod_python content handler? Are mod_python content handlers being used
exclusively to deliver up content, or are you just using mod_python
as a way of processing the SSL stuff and content handler phases would
be handled by non mod_python handlers such as PHP, CGI or static
page delivery?
The reason I am prying is that in Vampire, it notionally splits the
content handler phase into two parts. There is still the execution of
a handler to deliver up the content, but there is also a new phase
introduced of loginhandler. By default this implements a basic user
authentication scheme in the style of mod_python.publisher across
traditional content handlers. The default loginhandler can though be
replaced with your own which implements some other mechanism such as
one which uses sessions and forms based login screens. Because this
loginhandler is executed notionally within the Apache content handler
phase, it will have access to the SSL environment that you have
found is only added if req.add_common_vars() is called from the
content handler itself and not earlier phases.
Thus, with the appropriate configuration information to enable it,
you could with Vampire have:
from mod_python import apache
import vampire
def loginhandler(req):
req.add_common_vars()
req.subprocess_env['insideAuthH']='valueSetFromAuthH'
req.user='pippo'
#return apache.HTTP_UNAUTHORIZED
# Call through to original default loginhandler.
return vampire.loginhandler(req)
def handler(req):
#req.add_common_vars()
req.subprocess_env['pytest']='itWorksFromPublisher'
req.content_type = "text/plain"
req.write("Environment Variables\n----------------------\n\n")
for item in req.subprocess_env.items():
req.write("%s: %s\n" % item)
req.write("\n\n")
return apache.OK
For an example of using the Vampire loginhandler for implementing a
session based login mechanism see code in:
http://svn.dscpl.com.au/vampire/trunk/examples/session/
The "login.py" file contains both the loginhandler and the code which
implements the login form.
To see the actual code in action, go to:
http://www.dscpl.com.au/projects/vampire/examples/session
The username and password are in the "login.py" code.
The nice thing about the Vampire loginhandler is that this sort of code
is extracted out into one place and can encompass requests against
static
pages or mod_python based content handlers for that directory. Each
actual
content handler doesn't need to worry about dealing with the details of
having to create the session. If a handler needs access to the session
object, it just needs to access "req.session" object put there by the
loginhandler.
Now, whether this would at all be useful would be dependent on what you
are
using the SSL information for. Even if it isn't strictly part of a login
mechanism, it could still be done in the login handler, you just need
to call
through to the original default login handler as shown in code above if
not actually wanting to override it.
Hope this is of interest.
BTW, if you don't know what Vampire is, it is some customisations on top
of mod_python which to me make it easier to use. It isn't really a
framework
in any sense as it doesn't strictly dictate you do things in a certain
way.
In some ways it gives you more options, although it does tend to promote
a more resource based view of handler selection as opposed to a handler
per directory.
Web site is at:
http://www.dspcl.com.au/projects/vampire
Graham
On 21/05/2005, at 12:04 AM, Bud P. Bruegger wrote:
> Hi Graham,
>
> many thanks for your input! This got me a round further. I tried
> both the access and the fixup handlers (it needs to be before
> mod-rewrite does its things) and they are invoked (as opposed to the
> authen and authenz handlers).
>
> My remaining problem is that I don't see SSL_CLIENT_S_DN in the
> handler (after req.add_common_vars() and dumping the keys of
> req.subprocess_env). (I can see them w/o problems in the standard
> handler.) I have tried to play with the order of directives, but it
> didn't seem to make a difference. (see the apache conf snipplet below
> for details)
>
> Any idea how to access SSL_CLIENT_S_DN in the access or fixup handler?
>
> many thanks!
>
> -b
>
>
>
> <Directory /var/www/sc>
> SSLRequireSSL
> #SSLOptions +StdEnvVars +ExportCertData +FakeBasicAuth
> +StrictRequire
> SSLOptions +StdEnvVars +ExportCertData +StrictRequire
> SetHandler mod_python
> PythonHandler test
> PythonFixupHandler test
> PythonDebug On
> </Directory>
>
> At 08.52 20/05/2005 +1000, Graham Dumpleton wrote:
>
>> On 20/05/2005, at 12:27 AM, Bud P. Bruegger wrote:
>>
>>> I'm a beginner and hope someone can straighten me out.
>>>
>>> I am trying to write a simple handler that clicks in after mod-ssl
>>> has requested a certificate from the client. Depending on the type
>>> of client token (European eID cards), I'd like the handler to look
>>> at the client's subject DN derive (by string manipulation or by
>>> lookup) a nationally unique ID for the card holder.
>>>
>>> Sounds simple enough--but I can't get it to work. I tried both, the
>>> authen and the authz handlers. But neither from mod-ssl's
>>> +fakeBasicAuth nor from the handlers req.user = 'xxx' do I get a
>>> REMOTE_USER env variable set. Also the test evironment variable
>>> that I try to set in the authen/authz handler doesn't have effect.
>>
>> Normally the authenhandler will only be called if the Apache
>> configuration has
>> something like:
>>
>> AuthType Basic
>> AuthName "Restricted Files"
>> AuthUserFile /Users/grahamd/Sites/auth/pwdb
>>
>> Ie., it is triggered of the presence of these special Auth options.
>> Similarly,
>> the authzhandler only get called if other appropriate options for it
>> are
>> defined. Your SSL stuff doesn't seem to fit under that model and so
>> the
>> handlers may simply not be getting called.
>>
>>> Does this possibly mean that the authen/authz handlers are not
>>> called at all in my configuration? Should I use a different handler
>>> and which? Or did I simply mess up something else?
>>
>> Try adding a req.log_error() call in the handlers to see if they get
>> called or not.
>> Message will be in the Apache error log file.
>>
>> Does your code work if you move what you have in the authenhandler
>> into the start
>> of your actual handler function? Ie., does the concept at least work?
>>
>> As a fudge, you could always stick it in the accesshandler, which
>> from memory is
>> always called if defined.
>>
>> Graham
>
>
> -----------------------------------------------------------------------
> --------------------------
> Ing. Bud P. Bruegger, Ph.D. +39-0564-488577 (voice),
> -21139 (fax)
> Servizio Elaborazione Dati e-mail:
> bud at comune.grosseto.it
> Comune di Grosseto
> http://www.comune.grosseto.it/cie/
> Via Ginori, 43
> http://OpenPortalGuard.sf.net
> 58100 Grosseto (Tuscany, Italy) jabber: bud at amessage.info
>
> Free Software in Public Administration: not just a good idea, but a
> necessity
>
> Perfection is attained, not when there is nothing more to be added,
> but when there is nothing more to be taken away -- Antoine de
> Saint-Exupery
|