hello carsten. thanks for bringing this up. multi-tenancy is very important for our projects. but to be honest, until now i did not see that any of the current tenant api implementation [2] is of much use for user usecases.
let's start with the detecting of a tenant: * if adapting from a resource resolver, detection by user is done. but this implies that every user is exactly assigned to one tenant, which is - at least in our projects - not always the case. there are always users that have access to multiple tenants, controlled via ACLs. so this is not a 1:1 relation, but a 1-to-many relation. * if adapting from a resource a path-based detection is used. here i do not fully understand which path is meant - the path to the content of the tenant (e.g. /content/*), or the path to custom scripts used in script resolution (comparable to /apps/*). i do not get the distinction from your RT as well - you refer only to the script resolution part. but if adapting from a resource, this is usually a content resource, not a resource pointing to a script. in my opinion both is relevant - to be able to connect one or multiple subtrees in the content resource hierarchy with a specific tenant, and to allow to provide tenant-specific script overlays. in a 1:1 releation user->tenant the content dependency could be modeled via ACLs, but if you have one user that can access multiple tenants this does not work. besides this for our usecases the option to provide tenant-specific script resources has no high prio. much more importance is the possibility to create tenant-specific configuration. this may apply OSGi services, which currently support only one global configuration (ore one per runmode combination). on the other side this applies to other application-specific business logic which should behave differently from site to site or from tenant to tenant. btw. we should perhaps first start to define what we mean with the term "tenant". this much-used and overloaded term might be a source of confusion as well. in my view a tenant is in its smallest form e.g. one "site" (homepage and all content pages below), perhaps plus a separate area for media assets. but a tenant can also be a huge entity consisting of a lot of sites and other content. because even for a huge tenant there might be the need for different configuration for different sites/areas of the content we are currently thinking if we even need support for nested tenants, which allow a configuration parameter inheritance between the inner and outer tenants, up to the global level of OSGi configurations. for the configuration topic perhaps a separate RT should be started, but it's closely related to a tenant concept. stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:cziege...@apache.org] >Sent: Monday, August 11, 2014 1:18 PM >To: dev@sling.apache.org >Subject: [RT] Multi Tenancy > >Hi, > >we've seen a lot of different dicsussions over time wrt multi tenancy in >this list. In addition, there is the age old proposal at [1] and the tenant >module in [2] which superceeds parts of the proposal on the wiki >The current tenant module detects the tenant of a request either based on >the requested content path or the user home and provides this information >via an adapter factory for both, the resource resolver and a resource. >While this mechanism might not be sufficient, I think the key point here is >that you get the tenant by adapting the resource resolver - which actually >allows to do any detection being it path based, or based on the url, a >cookie whatever. In that sense, it seems that this design is sufficient. >When it comes to content, structuring content by tenant and using ACLs to >protect this seems to be sufficient as well. > >Now, the tricky and yet unsolved part is resource and script resolution. >The idea outlined in [1] is imho obsolete because we now already have >tenant support. > >I think we can add tenant support to resource resolving and script >resolution without any further api changes: both implementation can try to >adapt the resource resolver to a Tenant and then the resource resolver >implementation can use this extra information for lookups. The script >resolver uses the resource resolver anyway, the only thing needed to be >added there is that caching of script resolution should take the tenant >into account. > >My suggestion is that, if the Tenant information is availabe, resource >resolving looks at three places. For example if "foo/bar" should be >resolved: > >1. /tenants/{tenandId}/foo/bar >2. /apps/foo/bar >3. /libs/foo/bar > >The first available will be used. > >I think there is no need for several search paths per tenant or to make >this further configurable > >WDYT? > >Regards >Carsten > > >[1] https://cwiki.apache.org/confluence/display/SLING/Multitenancy+Support >[2] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/tenant >-- >Carsten Ziegeler >Adobe Research Switzerland >cziege...@apache.org
