> -----Original Message----- > From: Justin Edelson [mailto:[email protected]] > Sent: Tuesday, October 05, 2010 3:57 PM > To: [email protected] > Subject: Re: [DISCUSS] switching off Basic Auth as default? > > On 10/5/10 4:44 AM, 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]). > To boil it down, the problem identified in SLING-1765 is that if a user > logs into the OSGi web console and then visits any Sling application > (including, but not limited to, the Sling Explorer), the user is still > logged in. > > There are three things which come to my mind about this: > 1) The problem is that the Felix web console uses Basic Auth, not that > Sling supports preemptive Basic Auth. Therefore, we should be changing > the web console, not Sling's default configuration. > > 2) Couldn't you work around this by removing the > org.apache.sling.extensions.webconsolesecurityprovider bundle and making > it so that the Jackrabbit and Felix admin passwords weren't the same? > > 3) Aren't we talking about a relatively small number of advanced users? > The OSGi web console doesn't have any kind of RBAC, so I can't imagine > we're talking about end users or even normal content editors being > impacted here. If someone can be trusted to muck around with the OSGi > web console, they should be able to understand how to resolve the > scenario described.
I don't agree here: The problem is not the web console itself, the real Basic Auth issues are how browsers treat Basic Auth. And with Basic Auth enabled this affects not only advanced users but all users of an application using Basic Auth. > > > > 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. > I don't agree with this at all. IMHO, Basic Auth is preferable for > command-line tools, scripts, and the like. I think Sling is more about web application running in the browser than command line tools - and as saidf before, the issues with Basic Auth apply mostly to browsers. But read on... > > > > > 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... > See http://markmail.org/message/pvria2dxnifmllmu. I've been short on > time and trying to get the Emma integration done, but as soon as that's > finished, I can start integrating the ConfigAdmin/Launchpad code. > > Without this support, you can pretty easily do something similar with a > component like this: http://gist.github.com/611550 But to end this discussion: I don't think it's worth to fight about if Basic should be enabled or not, but maybe it's worth to think about some possibility to take Sling as it is and put in a single conf file into the jar or the directory to set all defaults like one wants to have them, without having to patch the source code like Ian mentioned (change annotations...) best regards mike > Justin > > > > > [1] http://markmail.org/thread/nmcjhvq46ihok7p2 > > [2] https://issues.apache.org/jira/browse/SLING-1765 > > > > best regards > > mike
