Hi, I don't have any hard feelings here, both ways are basically ok for me.
On the other hand, given... * we documented how to use HTTP Basic Auth with cURL * we use HTTP Basic auth in the integration tests * Web Console is no intended for the average user I tend to be slightly biased towards keeping HTTP Basic authentication active in preemptive mode. To fix the Web Console problem, I created FELIX-2639 [1] to enhance the security provider mechanism. Once we have FELIX-2639 fixed we can enhance our own security provider to use Auth Core for authentication and have solved the problem. WDYT ? Regards Felix [1] https://issues.apache.org/jira/browse/FELIX-2639 On 05.10.2010 10:44, Mike Müller wrote: > Hi > > As of the discussion in [1] I like to start a new discussion > about whether to disable or enable Basic Auth per default. > The initial reason to disable it, were the problems appeared > in the Sling Explorer after logging in under /system/console > with Basic Auth (SLING-1765 [2]). > > With Basic Auth on we've got serveral issues in the browsers: > - Some browsers pass credentials even on parent paths > where credentials should not be sent. > - Logout is mostly a problem > > With other clients than browsers these issues doesn't exist. > > I think we agree on the fact that it would be better/safer > to disable Basic Auth if there would not be a backward > compatibility issue with it. > > What crossed my mind is, that it would be very pratical to > have something like a conf file where you can overwrite > defaults from components as you wish. The conf file should > be placed into the Sling launchpad which reads the properties > and overwrites the defaults. But that's a little bit off topic here, > but would solve the problem that someone has to patch > the source only because of another default value... > > [1] http://markmail.org/thread/nmcjhvq46ihok7p2 > [2] https://issues.apache.org/jira/browse/SLING-1765 > > best regards > mike >
