1. cherrypy
  2. CherryPy
Issue #683 resolved

proposed recipe for digest authorization

Anonymous created an issue

Hi,

I've been wondering if CherryPy is the right place for doing authorization. Because instead of coding authorization it is easier to declare it in the front web servers. Instead of re-inventing the wheel, let the right tool handle the job.

IMHO it is the Right Thing (TM) to do, since it also makes sense to use a reverse proxy (apache/lighttpd/squid) in front of CherryPy to deal with buffer overflows, malformed URLs and other nasty things. This allows CherryPy to run in session-less mode, which allows for easier fail-over or load balancing.

Here is quick-and-dirty solution with lighttpd. Relevant lines from lighttpd.conf are :BR server.modules = (BR "mod_access",BR "mod_auth",BR "mod_proxy",BR "mod_accesslog" )BR server.port = 8090BR proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => 8080 ) ) )BR auth.backend = "plain"BR auth.backend.plain.userfile = "/opt/local/etc/lighttpd/lighttpd.user"BR auth.require = ( "/" => (BR "method" => "digest",BR "realm" => "cubulus",BR "require" => "valid-user"BR ) )BR

CherryPy receives header 'Authorization' with content 'Digest username="a", realm="cubulus", nonce=.., uri=.. qop="auth" ..... '

Easy thing is that if authorization fails, CherryPy receives.. nothing, so it's enough to look for Digest username="XXX"

Cheers, Alexandru http://alexandrutoth.blogspot.com/2007/04/digest-authentication-in-cherrypy_04.html

Reported by alexandru.toth@.nospam.gmail.com

Comments (6)

  1. Robert Brewer

    There's nothing stopping you from setting up your site that way. But CherryPy is never going to ''require'' Apache/lighttpd/squid, so I'm not sure what change you're proposing.

    If you want a front-end (like Apache) to do Digest authentication for you, then the chunk of code that connects it to CherryPy should set the request.login attribute to the name of the authenticated user. For example, the provided _cpmodpy module contains the line:

       request.login = req.user
    

    It's not safe for CherryPy to read the Authorization header and assume some other code has already vetted it.

  2. guest

    Looking at the Apache mod_auth digest it sais: "it has not been extensively tested and is therefore marked experimental". In lighttp mod_digest documentation, there is a limitation: "The implementation of digest method is currently not completely compliant with the standard as it still allows a replay attack".

    I mean no offense to the CherryPy, but I would assume more people use Apache and lighttpd '''authentication''', therefore higher probability to have the security fixed in the webservers. If hacker manages to manipulate the headers and reach CherryPy port, then I would say this is a bug in Apache / Lighty code.

    Proposal makes authentication "ortogonal" : if one needs it, it can be configured in said web servers. Otherwise, all web users are "anonymous". And there is content that can be served to anonymous users.

    Cheers, Alexandru

  3. guest

    For Intranet deployments, most users would appreciate not to see "Login" dialog at all. Proposal allows Single-Sign-On by using Windows Integrated Authentication (using IIS, not sure about Apache), and possibly on the Mac ("kerberized" applications)

    Cheers, Alexandru

  4. Robert Brewer

    Er, again, nothing's stopping you from using CherryPy in this way. If you've set up your site behind Apache and trust that any Authorization header has already been verified, feel free. But it's never going to be the default, because Apache is never going to be a mandatory prerequisite for CherryPy. If you have more tips about how to set it up the way you describe, you should expand on the topic at http://tools.cherrypy.org/wiki/ExternalAuth.

  5. Log in to comment