On 2 August 2010 02:22, Nikita Kalashnikov <[email protected]> wrote: > 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.
Digest authentication is fiddly from memory, so not surprised if there isn't a good one out there for Python. > 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. The only way you will do that is to write a custom Apache authentication handler which will fake up user credentials as anonymous if none supplied. I have seen this before as example in book on writing Apache modules. Not at home right now so cant check which book. Most likely something you don't want to do though. Graham > 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. > > -- 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.
