On 11.01.2013 23:53, [email protected] wrote: > Author: minfrin > Date: Fri Jan 11 22:53:50 2013 > New Revision: 1432322 > > URL: http://svn.apache.org/viewvc?rev=1432322&view=rev > Log: > mod_ssl: Allow the SSLUserName to be used to control the username passed > by the FakeBasicAuth option. PR52616.
[...] > -<p>Note that this directive has no effect if the > -<code>FakeBasicAuth</code> option is used (see <a > -href="#ssloptions">SSLOptions</a>).</p> > +<p>When the <code>FakeBasicAuth</code> option is enabled, this directive > +instead controls the value of the username embedded within the basic > +authentication header (see <a href="#ssloptions">SSLOptions</a>).</p> This patch changes the semantics of the FakeBasicAuth option in a non-obvious, but potentially backwards-incompatible/surprising way - imagine an existing configuration where SSLUserName is lying around and FakeBasicAuth is set (i.e., the former directive is ineffective / ignored by current mod_ssl versions). If someone is upgrading, then all of a sudden, the existing DN entries in an authn file become invalid, and if other (non-DN-based) entries are present which happen to map to the attribute specified with SSLUserName, cert-based authentication might allow access which wasn't intended in the first place. I would prefer a more explicit way of configuring this option (perhaps an additional SSLOption which is mutually exclusive with FakeBasicAuth). At least for the 2.4 backport, I think it's not appropriate to change the behavior in this rather silent way. Kaspar
