Hi, 2013/1/16 Felix Meschberger <[email protected]>
> Hi > > I like the second approach, too. I would think the property would be > accessed with the Authorizable.getProperty(String relPath) method. > > On a related note: Currently it is only possible to manage (create, read, > update, delete) through the Web Console. Would it make sense to define a > TenantManager service (which is not the same as the TenantProvider: While > the TenantProvider can be used by any one, the TenantManageris intended for > us by administrators). > > It makes totally sense to me. > Regards > Felix > > > > Am 16.01.2013 um 10:29 schrieb Timothée Maret: > > > Hi, > > > > I have been using the sling tenant recently and although the tenant path > > matcher configuration is > > flexbile, the user to tenant resolution mechanism enforces to organize > the > > users following a fixed > > structure where all the users must be under the tenantId root. > > > > As an example: > > > > /home/users/<tenantId>/bob > > /us/alice > > /fr/charles > > > > This is not flexible enough, especially with enabling tenant support on > > legacy system where users > > location is already set. > > > > I think there two approaches to improve that > > > > * Based on group > > > > Instead of being applied against the user home path, the regex could be > > applied against all the > > groups the user is a member of. Each tenant would be assigned to a > default > > group and the first > > tenant.default-group/user.group match would define the user as being part > > of the group. > > > > This offers the flexibility to store the user anywhere. However, the > > resolution would be undeterministic > > in cases where the user has more than one tenant group assigned. > Moreover, > > this would interleave > > group and tenant support which sounds like a limitation in comparison to > > the path based approach. > > > > * Based on property set in user home > > > > Each user part of a tenant would have a property "tenantId" set which > would > > map it to the tenant. > > This implies a bit more maintenance but would offer the flexibility to > > store users anywhere as well > > as a separation between group and tenants. > > > > To me, the property based is clearly the best way to go as it offers most > > flexibility in therms of > > group and user organization. Moreover, it could be implemented as an > > extension of the current design. > > Basically, instead of only trying to match against the user home path, > the > > TenantAdapterFactory could > > also look for the userHome + "tenantId" property path. If the property is > > present, then the value > > could be appended to the user home path and tried to be matched against > the > > regex. > > > > wdyt ? > > > > Regards, > > > > Timothee. > > Regards, Timothee.
