[mod_python] Sessions & user management

Please use reply-all and keep discussion on the list.

See comments below.

On 19/03/2008, Dominique.Holzwarth at ch.delarue.com
<Dominique.Holzwarth at ch.delarue.com> wrote:
>
>
>  Hello Grahamn
>
>  I've seen this section but there are several problems to me with it:
>
>  In the example:
>  __auth_realm__ = "Members only"
>
>   def __auth__(req, user, passwd):
>
>       if user == "eggs" and passwd == "spam" or \
>           user == "joe" and passwd == "eoj":
>           return 1
>       else:
>           return 0
>
>   def __access__(req, user):
>       if user == "eggs":
>           return 1
>       else:
>           return 0
>
>   def hello(req):
>       return "hello"
>
>  1. where does the data in the param's "user" and "passwd" come from?

The publisher handler internally implements HTTP basic authentication,
so comes from the WWW-Authenticate header passed by the browser.

>  2. I don't want to "hard-code" the user-id and password in my code. They rather should be stored in a file or so which would best be encoded (at least the password).
> Similar to the AuthFile-mechanism apache provides. But then again, I don't know how I would need to get that encoded data into my code... (to do the actual authentification...)

There is nothing to stop you doing that. When implementing __auth__
and __access__ as functions they could do quite complex things, like
consult external files. Thus it is up to you.

>  3. its written on that page, that for a "real" auth-mechanism "PythonAuthenHandler" should be used... So that's why I was asking for example on how to combine a "PythonAuthenHandler" with "PublisherHandler" and an AuthFile...

That comment is only in relation to the problem of code at global
scope in a module being executed even if a user doesn't strictly have
access. In other words, a non authenticated user can trigger side
affects. This is because the module has to be imported to be able to
consult the authentication and access information within it. It is not
generally a big issue.

Personally I would avoid both the publisher auth hooks and
PythonAuthenHandler. You would be better off using other Apache authnz
modules as they are more robust as they are better tested and give you
the option of using lots of different auth providers.

The bit that isn't obvious is how to apply them to mod_python and
publisher since publisher resources are not exclusively file based due
to a file handling multiple URLs.

Imagine though mod_python application is rooted at /myapp, then have:

<Location /myapp>

AuthType Basic
AuthName "Restricted Files"
AuthBasicProvider file
AuthUserFile /usr/local/apache/passwd/passwords
AuthGroupFile /usr/local/apache/passwd/groups

Require valid-user

</Location>

If specific URLs require more constrained access requirements based on
group member ship, then use:

<Location /myapp/admin>
Require group admin
</Location>

If you need access to who the user is in Python code, access req.user.

So, there is actually no need to do any in Python and standard Apache
mechanisms can be used. I don't generally suggest this though as
people are usually hell bent on doing everything in Python even though
Apache provides better stuff in other modules for doing it.

Graham

>  Greetings
>  Dominique
>
>
>  -----Original Message-----
>  From: Graham Dumpleton [mailto:graham.dumpleton at gmail.com]
>  Sent: Mittwoch, 19. März 2008 10:28
>  To: Holzwarth, Dominique (Berne Bauhaus)
>  Cc: mod_python at modpython.org
>  Subject: Re: [mod_python] Sessions & user management
>
>  In relation to authentication, have you read:
>
>   http://www.modpython.org/live/current/doc-html/hand-pub-alg-auth.html
>
>  Graham
>
>
> *********************************
>  This e-mail and any files attached are strictly confidential, may be legally privileged and are intended solely for the addressee. If you are not the intended recipient please notify the sender immediately by return email and then delete the e-mail and any attachments immediately. The views and or opinions expressed in this e-mail are not necessarily the views of De La Rue plc or any of its subsidiaries and the De La Rue Group of companies, their directors, officers and employees make no representation about and accept no liability for its accuracy or completeness. You should ensure that you have adequate virus protection as the De La Rue Group of companies do not accept liability for any viruses
>  De La Rue plc Registered No.3834125, De La Rue Holdings plc Registered No 58025 and De La Rue International Limited Registered No 720284 are all registered in England with their registered office at: De La Rue House, Jays Close, Viables, Hampshire RG22 4BS
>