You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Timothée Maret <ti...@gmail.com> on 2014/11/20 15:45:00 UTC
Adding AuthorizableMissmatchException to jackrabbit security API
Hi,
In a project, we have a utility method that allows to get or create an
authorizable of a given type (user or group).
In case the method can't return an authorizable of the required type (for
instance when requiring a group with id = X and a user with id = X already
exists), then
a org.apache.jackrabbit.api.security.user.AuthorizableExistsException is
thrown.
An AuthorizableExistsException does not precisely identify the root of the
error and maybe an exception of type AuthorizableMissmatchException would
be better.
Of course, we could add this exception in our project, however I thinking
it would be best to avoid adding extension of the JCR APIs at a project
level.
Therefor, would it make sense to add the exception
org.apache.jackrabbit.api.security.user.AuthorizableMissmatchException
to the Jackrabbit API ?
This exception would be thrown in any case (currently none in Jackrabbit)
where Jackrabbit can't return an Authorisable of a given type.
Regards,
Timothee
Re: Adding AuthorizableMissmatchException to jackrabbit security API
Posted by Timothee Maret <tm...@adobe.com>.
Hi,
I have opened [0,1] and attached a patch (Angela’s solution).
Regards,
Timothee
[0] https://issues.apache.org/jira/browse/JCR-3836
[1] https://issues.apache.org/jira/browse/JCR-3837
On 04/12/14 13:13, "Timothee Maret" <tm...@adobe.com> wrote:
>Hi Angela and Toby,
>
>Thanks for your input. My mail client missed your replies, thus answering
>only now.
>The utility methods (users and groups) we want to implement have
>signatures similar to the one below:
>
>/**
> * This method get or create the required group using the provided {@link
>UserManager} user manager.
> * This method does not save changes to the user manager session.
> *
> * @param userManager the {@link UserManager} used to access or create the
>group
> * @param intermediatePath parent path where the group should be created
> * @param groupId the group identifier to be accessed/created
> * @return the existing or new {@link Group}
> * @throws AuthorizableMismatchException if an {@link Authorizable} does
>exist but is not a {@link Group}
> */
>Group getOrCreateGroup(UserManager userManager, String intermediatePath,
>String groupId)
> throws RepositoryException;
>
>The AuthorizableMismatchException extending RepositoryException.
>
>
>The implementation goes as follow
>
>Auth auth = getAuthorizable()
>If (auth is null) {
> return createGroup()
>} else if (auth not a group) {
> throw AuthorizableMismatchException
>} else return auth
>
>I think it would be great to have Angela¹s suggestion regarding allowing
>to specify the type when we get an Authorizable.
>However, since the set of possible Authorizable is fixed and limited, we
>may have a specific method for each type.
>
>Group getGroup(@Nonnull String id) throws AuthorizableTypeException
>User getUser(@Nonnull String id) throws AuthorizableTypeException
>
>
>
>The other approach (passing the type in the exception) would work fine as
>well.
>
>I¹ll JIRA an attach a patch.
>
>Regards,
>
>Timothee
>
>
>
>
>On 28/11/14 02:39, "Tobias Bocanegra" <tr...@apache.org> wrote:
>
>>On Thu, Nov 27, 2014 at 7:41 AM, Angela Schreiber <an...@adobe.com>
>>wrote:
>>> hi
>>>
>>> sure... that would also be an option... but i would be
>>> equally fine to extend the API with something like
>>>
>>> @CheckForNull
>>> <T> T getAuthorizable(@Nonnull String id, @Nonnull Class<T>
>>> authorizableClass)
>>> throws AuthorizableTypeException
>>that would be helpful as well.
>>
>>but FWIU his problem is that he wants to create a new user (or group)
>>and does not want to do an extra check if the creation fails to figure
>>out, which type of authorizable existed. I assume his current code
>>does:
>>
>>try {
>> createUser()
>>} catch (AuthorizableExistsExcetion e) {
>> Authorizable a = getAuthorizable();
>> if (a.isGroup()) {
>> throw new AuthorizableMismatchException();
>> }
>> throw e;
>>}
>>
>>regards, toby
>>>
>>>
>>> that would be convenient as the expected type of the authorizable
>>> (user or group) is quite often known.
>>>
>>> @timothee, feel free to request an improvement in JIRA.
>>>
>>> kind regards
>>> angela
>>>
>>>
>>> On 26/11/14 19:02, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>>
>>>>Hi,
>>>>
>>>>On Wed, Nov 26, 2014 at 2:41 AM, Angela Schreiber <an...@adobe.com>
>>>>wrote:
>>>>> Hi Timothee
>>>>>
>>>>> I don't see where this exception would be thrown during regular
>>>>> calls to the JR user management API.
>>>>>
>>>>> UserManager#getAuthorizable doesn't allow to pass a the desired
>>>>> type nor do specific methods exist to retrieve a user or group.
>>>>>
>>>>> So, I am not totally sure how this method fits into the current
>>>>> API.... IMO it would only make sense to have it if we at the same
>>>>> time introduce a new method like
>>>>>
>>>>> <T> T getAuthorizable(@Nonnull String id, Class<T> authorizableClass)
>>>>> throws AuthorizableTypeException
>>>>>
>>>>
>>>>I think Tim's problem is that he wants to either create a new user or
>>>>group, but the "opposite" authorizable with the same name already
>>>>exist.
>>>>
>>>>I think it's easiest to include a:
>>>> isUser() to the AuthorizableExistsException exception.
>>>>
>>>>so the code could test:
>>>>
>>>>try {
>>>> createUser(userId);
>>>>} catch (AuthorizableExistsException e) {
>>>> if (!e.isUser()) {
>>>> // group with 'userid' already exists
>>>> }
>>>>
>>>>regards, toby
>>>>
>>>>> or something similar.
>>>>>
>>>>> kind regards
>>>>> angela
>>>>>
>>>>>
>>>>>
>>>>> On 20/11/14 15:45, "Timothée Maret" <ti...@gmail.com> wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>
>>>>>>In a project, we have a utility method that allows to get or create
>>>>>>an
>>>>>>authorizable of a given type (user or group).
>>>>>>In case the method can't return an authorizable of the required type
>>>>>>(for
>>>>>>instance when requiring a group with id = X and a user with id = X
>>>>>>already exists), then a
>>>>>>org.apache.jackrabbit.api.security.user.AuthorizableExistsException
>>>>>>is
>>>>>>thrown.
>>>>>>
>>>>>>
>>>>>>An AuthorizableExistsException does not precisely identify the root
>>>>>>of
>>>>>>the error and maybe an exception of type
>>>>>>AuthorizableMissmatchException
>>>>>>would be better.
>>>>>>Of course, we could add this exception in our project, however I
>>>>>>thinking
>>>>>>it would be best to avoid adding extension of the JCR APIs at a
>>>>>>project
>>>>>>level.
>>>>>>Therefor, would it make sense to add the exception
>>>>>>
>>>>>>
>>>>>>org.apache.jackrabbit.api.security.user.AuthorizableMissmatchExceptio
>>>>>>n
>>>>>>
>>>>>>
>>>>>>to the Jackrabbit API ?
>>>>>>
>>>>>>
>>>>>>This exception would be thrown in any case (currently none in
>>>>>>Jackrabbit)
>>>>>>where Jackrabbit can't return an Authorisable of a given type.
>>>>>>
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>
>>>>>>Timothee
>>>>>>
>>>>>
>>>
>
Re: Adding AuthorizableMissmatchException to jackrabbit security API
Posted by Timothee Maret <tm...@adobe.com>.
Hi Angela and Toby,
Thanks for your input. My mail client missed your replies, thus answering
only now.
The utility methods (users and groups) we want to implement have
signatures similar to the one below:
/**
* This method get or create the required group using the provided {@link
UserManager} user manager.
* This method does not save changes to the user manager session.
*
* @param userManager the {@link UserManager} used to access or create the
group
* @param intermediatePath parent path where the group should be created
* @param groupId the group identifier to be accessed/created
* @return the existing or new {@link Group}
* @throws AuthorizableMismatchException if an {@link Authorizable} does
exist but is not a {@link Group}
*/
Group getOrCreateGroup(UserManager userManager, String intermediatePath,
String groupId)
throws RepositoryException;
The AuthorizableMismatchException extending RepositoryException.
The implementation goes as follow
Auth auth = getAuthorizable()
If (auth is null) {
return createGroup()
} else if (auth not a group) {
throw AuthorizableMismatchException
} else return auth
I think it would be great to have Angela¹s suggestion regarding allowing
to specify the type when we get an Authorizable.
However, since the set of possible Authorizable is fixed and limited, we
may have a specific method for each type.
Group getGroup(@Nonnull String id) throws AuthorizableTypeException
User getUser(@Nonnull String id) throws AuthorizableTypeException
The other approach (passing the type in the exception) would work fine as
well.
I¹ll JIRA an attach a patch.
Regards,
Timothee
On 28/11/14 02:39, "Tobias Bocanegra" <tr...@apache.org> wrote:
>On Thu, Nov 27, 2014 at 7:41 AM, Angela Schreiber <an...@adobe.com>
>wrote:
>> hi
>>
>> sure... that would also be an option... but i would be
>> equally fine to extend the API with something like
>>
>> @CheckForNull
>> <T> T getAuthorizable(@Nonnull String id, @Nonnull Class<T>
>> authorizableClass)
>> throws AuthorizableTypeException
>that would be helpful as well.
>
>but FWIU his problem is that he wants to create a new user (or group)
>and does not want to do an extra check if the creation fails to figure
>out, which type of authorizable existed. I assume his current code
>does:
>
>try {
> createUser()
>} catch (AuthorizableExistsExcetion e) {
> Authorizable a = getAuthorizable();
> if (a.isGroup()) {
> throw new AuthorizableMismatchException();
> }
> throw e;
>}
>
>regards, toby
>>
>>
>> that would be convenient as the expected type of the authorizable
>> (user or group) is quite often known.
>>
>> @timothee, feel free to request an improvement in JIRA.
>>
>> kind regards
>> angela
>>
>>
>> On 26/11/14 19:02, "Tobias Bocanegra" <tr...@apache.org> wrote:
>>
>>>Hi,
>>>
>>>On Wed, Nov 26, 2014 at 2:41 AM, Angela Schreiber <an...@adobe.com>
>>>wrote:
>>>> Hi Timothee
>>>>
>>>> I don't see where this exception would be thrown during regular
>>>> calls to the JR user management API.
>>>>
>>>> UserManager#getAuthorizable doesn't allow to pass a the desired
>>>> type nor do specific methods exist to retrieve a user or group.
>>>>
>>>> So, I am not totally sure how this method fits into the current
>>>> API.... IMO it would only make sense to have it if we at the same
>>>> time introduce a new method like
>>>>
>>>> <T> T getAuthorizable(@Nonnull String id, Class<T> authorizableClass)
>>>> throws AuthorizableTypeException
>>>>
>>>
>>>I think Tim's problem is that he wants to either create a new user or
>>>group, but the "opposite" authorizable with the same name already
>>>exist.
>>>
>>>I think it's easiest to include a:
>>> isUser() to the AuthorizableExistsException exception.
>>>
>>>so the code could test:
>>>
>>>try {
>>> createUser(userId);
>>>} catch (AuthorizableExistsException e) {
>>> if (!e.isUser()) {
>>> // group with 'userid' already exists
>>> }
>>>
>>>regards, toby
>>>
>>>> or something similar.
>>>>
>>>> kind regards
>>>> angela
>>>>
>>>>
>>>>
>>>> On 20/11/14 15:45, "Timothée Maret" <ti...@gmail.com> wrote:
>>>>
>>>>>Hi,
>>>>>
>>>>>
>>>>>In a project, we have a utility method that allows to get or create an
>>>>>authorizable of a given type (user or group).
>>>>>In case the method can't return an authorizable of the required type
>>>>>(for
>>>>>instance when requiring a group with id = X and a user with id = X
>>>>>already exists), then a
>>>>>org.apache.jackrabbit.api.security.user.AuthorizableExistsException is
>>>>>thrown.
>>>>>
>>>>>
>>>>>An AuthorizableExistsException does not precisely identify the root of
>>>>>the error and maybe an exception of type
>>>>>AuthorizableMissmatchException
>>>>>would be better.
>>>>>Of course, we could add this exception in our project, however I
>>>>>thinking
>>>>>it would be best to avoid adding extension of the JCR APIs at a
>>>>>project
>>>>>level.
>>>>>Therefor, would it make sense to add the exception
>>>>>
>>>>>
>>>>>org.apache.jackrabbit.api.security.user.AuthorizableMissmatchException
>>>>>
>>>>>
>>>>>to the Jackrabbit API ?
>>>>>
>>>>>
>>>>>This exception would be thrown in any case (currently none in
>>>>>Jackrabbit)
>>>>>where Jackrabbit can't return an Authorisable of a given type.
>>>>>
>>>>>
>>>>>Regards,
>>>>>
>>>>>
>>>>>Timothee
>>>>>
>>>>
>>
Re: Adding AuthorizableMissmatchException to jackrabbit security API
Posted by Tobias Bocanegra <tr...@apache.org>.
On Thu, Nov 27, 2014 at 7:41 AM, Angela Schreiber <an...@adobe.com> wrote:
> hi
>
> sure... that would also be an option... but i would be
> equally fine to extend the API with something like
>
> @CheckForNull
> <T> T getAuthorizable(@Nonnull String id, @Nonnull Class<T>
> authorizableClass)
> throws AuthorizableTypeException
that would be helpful as well.
but FWIU his problem is that he wants to create a new user (or group)
and does not want to do an extra check if the creation fails to figure
out, which type of authorizable existed. I assume his current code
does:
try {
createUser()
} catch (AuthorizableExistsExcetion e) {
Authorizable a = getAuthorizable();
if (a.isGroup()) {
throw new AuthorizableMismatchException();
}
throw e;
}
regards, toby
>
>
> that would be convenient as the expected type of the authorizable
> (user or group) is quite often known.
>
> @timothee, feel free to request an improvement in JIRA.
>
> kind regards
> angela
>
>
> On 26/11/14 19:02, "Tobias Bocanegra" <tr...@apache.org> wrote:
>
>>Hi,
>>
>>On Wed, Nov 26, 2014 at 2:41 AM, Angela Schreiber <an...@adobe.com>
>>wrote:
>>> Hi Timothee
>>>
>>> I don't see where this exception would be thrown during regular
>>> calls to the JR user management API.
>>>
>>> UserManager#getAuthorizable doesn't allow to pass a the desired
>>> type nor do specific methods exist to retrieve a user or group.
>>>
>>> So, I am not totally sure how this method fits into the current
>>> API.... IMO it would only make sense to have it if we at the same
>>> time introduce a new method like
>>>
>>> <T> T getAuthorizable(@Nonnull String id, Class<T> authorizableClass)
>>> throws AuthorizableTypeException
>>>
>>
>>I think Tim's problem is that he wants to either create a new user or
>>group, but the "opposite" authorizable with the same name already
>>exist.
>>
>>I think it's easiest to include a:
>> isUser() to the AuthorizableExistsException exception.
>>
>>so the code could test:
>>
>>try {
>> createUser(userId);
>>} catch (AuthorizableExistsException e) {
>> if (!e.isUser()) {
>> // group with 'userid' already exists
>> }
>>
>>regards, toby
>>
>>> or something similar.
>>>
>>> kind regards
>>> angela
>>>
>>>
>>>
>>> On 20/11/14 15:45, "Timothée Maret" <ti...@gmail.com> wrote:
>>>
>>>>Hi,
>>>>
>>>>
>>>>In a project, we have a utility method that allows to get or create an
>>>>authorizable of a given type (user or group).
>>>>In case the method can't return an authorizable of the required type
>>>>(for
>>>>instance when requiring a group with id = X and a user with id = X
>>>>already exists), then a
>>>>org.apache.jackrabbit.api.security.user.AuthorizableExistsException is
>>>>thrown.
>>>>
>>>>
>>>>An AuthorizableExistsException does not precisely identify the root of
>>>>the error and maybe an exception of type AuthorizableMissmatchException
>>>>would be better.
>>>>Of course, we could add this exception in our project, however I
>>>>thinking
>>>>it would be best to avoid adding extension of the JCR APIs at a project
>>>>level.
>>>>Therefor, would it make sense to add the exception
>>>>
>>>>
>>>>org.apache.jackrabbit.api.security.user.AuthorizableMissmatchException
>>>>
>>>>
>>>>to the Jackrabbit API ?
>>>>
>>>>
>>>>This exception would be thrown in any case (currently none in
>>>>Jackrabbit)
>>>>where Jackrabbit can't return an Authorisable of a given type.
>>>>
>>>>
>>>>Regards,
>>>>
>>>>
>>>>Timothee
>>>>
>>>
>
Re: Adding AuthorizableMissmatchException to jackrabbit security API
Posted by Angela Schreiber <an...@adobe.com>.
hi
sure... that would also be an option... but i would be
equally fine to extend the API with something like
@CheckForNull
<T> T getAuthorizable(@Nonnull String id, @Nonnull Class<T>
authorizableClass)
throws AuthorizableTypeException
that would be convenient as the expected type of the authorizable
(user or group) is quite often known.
@timothee, feel free to request an improvement in JIRA.
kind regards
angela
On 26/11/14 19:02, "Tobias Bocanegra" <tr...@apache.org> wrote:
>Hi,
>
>On Wed, Nov 26, 2014 at 2:41 AM, Angela Schreiber <an...@adobe.com>
>wrote:
>> Hi Timothee
>>
>> I don't see where this exception would be thrown during regular
>> calls to the JR user management API.
>>
>> UserManager#getAuthorizable doesn't allow to pass a the desired
>> type nor do specific methods exist to retrieve a user or group.
>>
>> So, I am not totally sure how this method fits into the current
>> API.... IMO it would only make sense to have it if we at the same
>> time introduce a new method like
>>
>> <T> T getAuthorizable(@Nonnull String id, Class<T> authorizableClass)
>> throws AuthorizableTypeException
>>
>
>I think Tim's problem is that he wants to either create a new user or
>group, but the "opposite" authorizable with the same name already
>exist.
>
>I think it's easiest to include a:
> isUser() to the AuthorizableExistsException exception.
>
>so the code could test:
>
>try {
> createUser(userId);
>} catch (AuthorizableExistsException e) {
> if (!e.isUser()) {
> // group with 'userid' already exists
> }
>
>regards, toby
>
>> or something similar.
>>
>> kind regards
>> angela
>>
>>
>>
>> On 20/11/14 15:45, "Timothée Maret" <ti...@gmail.com> wrote:
>>
>>>Hi,
>>>
>>>
>>>In a project, we have a utility method that allows to get or create an
>>>authorizable of a given type (user or group).
>>>In case the method can't return an authorizable of the required type
>>>(for
>>>instance when requiring a group with id = X and a user with id = X
>>>already exists), then a
>>>org.apache.jackrabbit.api.security.user.AuthorizableExistsException is
>>>thrown.
>>>
>>>
>>>An AuthorizableExistsException does not precisely identify the root of
>>>the error and maybe an exception of type AuthorizableMissmatchException
>>>would be better.
>>>Of course, we could add this exception in our project, however I
>>>thinking
>>>it would be best to avoid adding extension of the JCR APIs at a project
>>>level.
>>>Therefor, would it make sense to add the exception
>>>
>>>
>>>org.apache.jackrabbit.api.security.user.AuthorizableMissmatchException
>>>
>>>
>>>to the Jackrabbit API ?
>>>
>>>
>>>This exception would be thrown in any case (currently none in
>>>Jackrabbit)
>>>where Jackrabbit can't return an Authorisable of a given type.
>>>
>>>
>>>Regards,
>>>
>>>
>>>Timothee
>>>
>>
Re: Adding AuthorizableMissmatchException to jackrabbit security API
Posted by Tobias Bocanegra <tr...@apache.org>.
Hi,
On Wed, Nov 26, 2014 at 2:41 AM, Angela Schreiber <an...@adobe.com> wrote:
> Hi Timothee
>
> I don't see where this exception would be thrown during regular
> calls to the JR user management API.
>
> UserManager#getAuthorizable doesn't allow to pass a the desired
> type nor do specific methods exist to retrieve a user or group.
>
> So, I am not totally sure how this method fits into the current
> API.... IMO it would only make sense to have it if we at the same
> time introduce a new method like
>
> <T> T getAuthorizable(@Nonnull String id, Class<T> authorizableClass)
> throws AuthorizableTypeException
>
I think Tim's problem is that he wants to either create a new user or
group, but the "opposite" authorizable with the same name already
exist.
I think it's easiest to include a:
isUser() to the AuthorizableExistsException exception.
so the code could test:
try {
createUser(userId);
} catch (AuthorizableExistsException e) {
if (!e.isUser()) {
// group with 'userid' already exists
}
regards, toby
> or something similar.
>
> kind regards
> angela
>
>
>
> On 20/11/14 15:45, "Timothée Maret" <ti...@gmail.com> wrote:
>
>>Hi,
>>
>>
>>In a project, we have a utility method that allows to get or create an
>>authorizable of a given type (user or group).
>>In case the method can't return an authorizable of the required type (for
>>instance when requiring a group with id = X and a user with id = X
>>already exists), then a
>>org.apache.jackrabbit.api.security.user.AuthorizableExistsException is
>>thrown.
>>
>>
>>An AuthorizableExistsException does not precisely identify the root of
>>the error and maybe an exception of type AuthorizableMissmatchException
>>would be better.
>>Of course, we could add this exception in our project, however I thinking
>>it would be best to avoid adding extension of the JCR APIs at a project
>>level.
>>Therefor, would it make sense to add the exception
>>
>>
>>org.apache.jackrabbit.api.security.user.AuthorizableMissmatchException
>>
>>
>>to the Jackrabbit API ?
>>
>>
>>This exception would be thrown in any case (currently none in Jackrabbit)
>>where Jackrabbit can't return an Authorisable of a given type.
>>
>>
>>Regards,
>>
>>
>>Timothee
>>
>
Re: Adding AuthorizableMissmatchException to jackrabbit security API
Posted by Angela Schreiber <an...@adobe.com>.
Hi Timothee
I don't see where this exception would be thrown during regular
calls to the JR user management API.
UserManager#getAuthorizable doesn't allow to pass a the desired
type nor do specific methods exist to retrieve a user or group.
So, I am not totally sure how this method fits into the current
API.... IMO it would only make sense to have it if we at the same
time introduce a new method like
<T> T getAuthorizable(@Nonnull String id, Class<T> authorizableClass)
throws AuthorizableTypeException
or something similar.
kind regards
angela
On 20/11/14 15:45, "Timothée Maret" <ti...@gmail.com> wrote:
>Hi,
>
>
>In a project, we have a utility method that allows to get or create an
>authorizable of a given type (user or group).
>In case the method can't return an authorizable of the required type (for
>instance when requiring a group with id = X and a user with id = X
>already exists), then a
>org.apache.jackrabbit.api.security.user.AuthorizableExistsException is
>thrown.
>
>
>An AuthorizableExistsException does not precisely identify the root of
>the error and maybe an exception of type AuthorizableMissmatchException
>would be better.
>Of course, we could add this exception in our project, however I thinking
>it would be best to avoid adding extension of the JCR APIs at a project
>level.
>Therefor, would it make sense to add the exception
>
>
>org.apache.jackrabbit.api.security.user.AuthorizableMissmatchException
>
>
>to the Jackrabbit API ?
>
>
>This exception would be thrown in any case (currently none in Jackrabbit)
>where Jackrabbit can't return an Authorisable of a given type.
>
>
>Regards,
>
>
>Timothee
>