On Tuesday 28 March 2017 15:01:47 Carsten Ziegeler wrote: > 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.
Having a service user per bundle shifts away the amount of configuration from service user mapping to repoinit only, right? Currently we have several bundles using one service user only, e.g. sling- scripting oder sling-readall. Regards, O. > 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]
