Thanks for the reply Graham. Didn't know about these config options. The idea was to use apache's mod_auth_digest in place of a proper repoze.who authenticator so that I don't have to write my own python digest code and spend any more time on this than I have to. I'm actually a bit surprised I wasn't able to find an implementation, I'm probably not looking in the right places. In any case, if authentication fails, REMOTE_USER would be empty, and authorization could be performed for an anonymous user. That's a valid use case in my application, I don't necessarily need to know anything about the user unless it's certain specific pages. The wsgi application itself would send the auth challenge, not apache, if it was necessary.
I guess the point is that apache's authorization providers were designed to run as a stand alone security mechanism, minus the auth function. Satisfy might work, but sounds a bit too hacky, as do multiple authorizers. Since none of these approaches accurately reflect what I actually want to do, I think I'll go with AuthKit's digest implementation essentially copied to repoze.who keeping the entire flow within the same layer, and see how that works out. Nikita On Jul 31, 8:26 pm, Graham Dumpleton <[email protected]> wrote: > On 31 July 2010 23:36, Nikita Kalashnikov <[email protected]> > wrote: > > > Hi, > > > I've encountered an issue where after configuring Digest auth as > > described herehttp://code.google.com/p/modwsgi/wiki/AccessControlMechanisms, > > the authentication function get_realm_hash is not invoked unless in > > the apache config you set "Require valid-user". > > Yes, this is expected behaviour for Apache. Apache will not do > authentication/authorisation unless a Require directive is specified. > > > If I do include this > > directive, and my auth function doesn't find a matching user, apache > > immediately sends a 401 to the client. > > Yes, again is expected Apache behaviour. > > The best one can manage with Apache is to define multiple > authentication providers and designate that earlier ones are non > authoritative, such that fail in authenticating user, that latter > authentication providers get a crack at it. > > The directive in mod_wsgi for indicating whether it is authoritative > is WSGIUserAuthoritative. By default it is On. > > > What I want it to do is to > > continue with the request and invoke the wsgi app. > > That you cant do. There must be an authentication provider setup in > Apache which says that it accepts the credentials to get beyond the > Apache authentication phase. > > > I would then use > > authorization code downstream to determine what can and can't be > > accessed. > > Based on what? > > Authentication and authorisation are two separate things. Before being > able to do authorisation you must have authentication credentials > supplied from the authentication phase. > > The only way you could do it otherwise in Apache (and for that you > need Apache 2.3), is stacked authentication handlers with the latter > being provided by mod_authn_anon. > > In other words, if not a registered user then user must log in as > 'anonymous' and depending on configuration supply an email address as > password. See: > > http://httpd.apache.org/docs/2.3/en/mod/mod_authn_anon.html > > This allows you to get past authentication and perform authorisation > using Apache or within the application. > > > For anyone familiar with how repoze.who works for example, it can > > happily find no matching user during the authentication step, and let > > your downstream authorizers handle that. > > > This digest thing is semi temporary, but I'm curious if this can be > > considered a bug, or if I'm misunderstanding apache's mod_auth_digest > > somehow. Seems like "Require valid-user" shouldn't be required for the > > authentication function to be called. > > It is not a bug, it is how Apache works. > > > If there is no easy work around, I'll have to implement digest within > > repoze.who, which currently only has basic auth from what I see. > > Thankfully AuthKit has a complete reference python implementation. > > If you cant work within how Apache does things, that may be your only choice. > > Before ruling out whether you can do what you want, you might look at > the Satisfy directive in Apache. > > http://httpd.apache.org/docs/2.2/mod/core.html#satisfy > > I have never played with this, but reading the documentation it may be > able to help. > > My only concerns with that is how you force the browser to pop up the > login popup. You may have to have a specific login page URL which > still has Satisfy All such that can force the login popup to come up > such that users can supply their credentials. > > Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
