Hi Ian, Ian Boston schrieb: > Hi, > > IMHO the changes to the AuthorizableImpl in JR 1.6 are problematic > This relates to the following set of properties. > > rep:principalName > rep:userId > rep:referees > rep:groups > rep:impersonators > rep:password > > Prior to 1.6 a request > curl http://admin:ad...@localhost:8080/system/userManager/user/admin.json > gave something like > { > rep:userId : admin > rep:principalName: admin > .... > } > > rep:password might have been there and should not have been, however now > curl http://admin:ad...@localhost:8080/system/userManager/user/admin.json > > gives > {}
Yes, this is a thing which changed from JR 1.5 to 1.6: Authorizable.getProperties() method now only returns "real" properties. The internal properties representing data to be returned by spezialized methods are not returned any longer. JR uses the property definition to decide whether a property is to be returned or not: If it is not protected and is part of the rep:Authorizable it is returned. This excludes the special properties. > > There is no way of doing anything useful with this response, other than > deducing from the URL that the userid probably was admin and the > principalName might have been admin. > > ------------------------------------ > 2 questions. > > 1. > Would it be acceptable to add some of these properties back into the > AuthorizableValueMap so that the response become useful ? > > eg > > rep:principalName > rep:userId > rep:referees > rep:groups > rep:impersonators I could well imagine that Sling could be extended to still return these as part of its AuthorizableResource ValueMap as. Where rep:userId would probably be just rep:id and another (boolean) property rep:isGroup would be added to represent the authorizable as a group instead of a user. of course returning a rep:password property does not make any sense (as you said). > > 2. > Is there any chance that JR is going to distinguish between read-deny and > read-only properties on authorizables ? What do you mean ? I don't think JR will return these properties as part of the Authorizable.getPropertyNames() any more because form the POV of JR it does not make sense and might expose implementation details. > > Ian > > > >
