On Thu, Jan 16, 2014 at 11:02 PM, Kean Johnston <[email protected]>wrote:
> This module registers itself as an authentication provider with > ap_register_auth_provider(). However, it *also* registers as a hook with > ap_hook_check_authn(). The two cases are similar, but subtly different (the > latter sets r->user, the former does not). My question is, why would you > need both? What functionality is gained by the hook? Provider is nice and simple and fits nicely with most bundled authn implementations. The lower-level API is required to provide some additional features: 1. allowing the FastCGI app to control the response body on failure 2. allowing the user id to be determined by different mechanisms 3. (possibly something else I forgot) FastCGI authorizers running under Zeus had these capabilities, and they were implemented here to support migration of an authorizer from Zeus. (The first item listed is a feature of the FastCGI spec that had not been implemented before for Apache httpd AFAICT.) > Also, I see code that prevents authz from running if its a combined > authn/authz, but nothing to prevent the FastCGI backend being called twice > for authn. Both fcgi_check_authn() and fcgi_check_password() call the > FastCGI application with the same role. I don't understand enough about the > authn pipeline to know if this is prevented in some other way. Any > clarification greatly welcomed. mod_authnz_fcgi runs before mod_auth_basic; the authoritative flag controls whether or not it can allow basic "providers" (potentially including a FastCGI-based provider) to try to authenticate. > > > Kean > -- Born in Roswell... married an alien... http://emptyhammock.com/
