Julian Sedding wrote > Hi Carsten > > I fully agree with the intention of your email. > > As a convention for service users, would it make sense to use the > bundle-symbolic-name as the user-ID (or principal-name)? If we can > detect the class name of the service that's creating the > Session/ResourceResolver, we could even use the fully qualified > classname. Not sure that there is a way other than inspecting the call > stack, however.
Yes, I guess that is maybe somehow doable. We could use the bundle symbolic name and the sub service information. That should be enough. We don't need the class name. It's very unlikely that users with that name exist out of the box. That would free us from most of the mapping configurations. What do others think? > > > IIUC the service user mapping is only one part of the story. The other > part are the permissions required by a service user. I suppose > permissions are also a kind of configuration? So how would we go about > having a working default permission setup? Without that, a convention > for service users becomes kind of pointless. Or am I missing > something? Yes, we need the repoinit stuff for this, actually we need repoinit for two things: setting up a user (we shouldn't do this automatically) and setting up the ACLs. Carsten > > Regards > Julian > > > On Mon, Mar 27, 2017 at 4:02 PM, Carsten Ziegeler <[email protected]> > wrote: >> Hi, >> >> for a long time we have tried to use sensible defaults for all of our >> configurations. This allows our users to run a default Sling without any >> additional configuration (it should even be possible to run it without a >> Configuration Admin service available - but that's another story). >> >> While we were pretty successful with this, we simply blew it with the >> move from login administrative to service users. A lot of the (core) >> modules now use service users and these require a configured mapping in >> order to work properly. While for example the servlets resolver >> previously did not require any configuration, it requires at least the >> mapping. Which in turn means you can't simply use that module as-is. >> >> Switching to service users is of course a good idea but I'm wondering if >> we can find a way to get back to a configurationless Sling again? >> >> Clearly we don't want to the mapping to be part of the bundles using the >> service users. >> >> One possible solution would be an out of the box bundle with the >> necessary repo init and configurations. This would cover the core >> bundles like servlets resolver and resource resolver. >> >> But maybe there is a better option? >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> [email protected] > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
