[
https://issues.apache.org/jira/browse/SLING-1555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Norman updated SLING-1555:
-------------------------------
Description:
It would be nice if the jackrabbit.usermanager bundle exposed OSGI service(s)
that maps exactly the functionalities of the REST services, so that one can use
their features also in a programmatic way.
This can be useful if an application has to manage users and groups without
having an explicit request object (ex: from an EventListener), or in the case a
user has to manipulate his account (in this case he doesn't have an
administrative account, so his requests are not permitted to modify users).
Also i think that, in certain situations, it could be just cleaner and simpler
to write a servlet or script that directly invoke the methods, instead of find
the way to invoke the REST services.
I think a simple but exaustive way to achieve this can be the direct mapping of
the REST services described in
http://sling.apache.org/site/managing-users-and-groups-jackrabbitusermanager.html
and
http://sling.apache.org/site/managing-permissions-jackrabbitaccessmanager.html,
only using well-known JCR classes.
For example, obtaining the users list could be as simple as getting the
UserManager OSGI service and invoking a method like "public NodeIterator
listUsers()", changing a permission could be achieved by getting the
AccessManager OSGI service and invoking a method like "public void
modifyPermission(String node_path, String principalId, String privilege_name,
String privilege_value, String order)", and so on...
Perhaps the best way to standardize these services is a dedicated API that
formalizes the underlying concepts (ex: User, Group, Privilege and
NodeAccessControl... if you think it's the case, i could propose my own...),
but i think the simple REST services mapping could already be a nice (and
ready-to-go) feature for developers...
was:
It would be nice if the jackrabbit.accessmanager and jackrabbit.usermanager
bundles expose OSGI service(s) that maps exactly the functionalities of the
REST services, so that one can use their features also in a programmatic way.
This can be useful if an application has to manage users and permissions
without having an explicit request object (ex: from an EventListener), or in
the case a user has to manipulate his account (in this case he doesn't have an
administrative account, so his requests are not permitted to modify users).
Also i think that, in certain situations, it could be just cleaner and simpler
to write a servlet or script that directly invoke the methods, instead of find
the way to invoke the REST services.
I think a simple but exaustive way to achieve this can be the direct mapping of
the REST services described in
http://sling.apache.org/site/managing-users-and-groups-jackrabbitusermanager.html
and
http://sling.apache.org/site/managing-permissions-jackrabbitaccessmanager.html,
only using well-known JCR classes.
For example, obtaining the users list could be as simple as getting the
UserManager OSGI service and invoking a method like "public NodeIterator
listUsers()", changing a permission could be achieved by getting the
AccessManager OSGI service and invoking a method like "public void
modifyPermission(String node_path, String principalId, String privilege_name,
String privilege_value, String order)", and so on...
Perhaps the best way to standardize these services is a dedicated API that
formalizes the underlying concepts (ex: User, Group, Privilege and
NodeAccessControl... if you think it's the case, i could propose my own...),
but i think the simple REST services mapping could already be a nice (and
ready-to-go) feature for developers...
Affects Version/s: (was: JCR Jackrabbit Access Manager 2.0.4)
Assignee: Eric Norman
Labels: api programmatically service usermanager (was:
accessmanager api programmatically service usermanager)
Summary: UserManager permissions manipulation services API (was:
Users and permissions manipulation API)
Split the original issue into two defects to handle the services api for
usermanager and accessmanager separately
> UserManager permissions manipulation services API
> -------------------------------------------------
>
> Key: SLING-1555
> URL: https://issues.apache.org/jira/browse/SLING-1555
> Project: Sling
> Issue Type: Improvement
> Components: API
> Affects Versions: JCR Jackrabbit User Manager 2.1.0
> Reporter: Fabrizio Scarcello
> Assignee: Eric Norman
> Labels: api, programmatically, service, usermanager
>
> It would be nice if the jackrabbit.usermanager bundle exposed OSGI service(s)
> that maps exactly the functionalities of the REST services, so that one can
> use their features also in a programmatic way.
> This can be useful if an application has to manage users and groups without
> having an explicit request object (ex: from an EventListener), or in the case
> a user has to manipulate his account (in this case he doesn't have an
> administrative account, so his requests are not permitted to modify users).
> Also i think that, in certain situations, it could be just cleaner and
> simpler to write a servlet or script that directly invoke the methods,
> instead of find the way to invoke the REST services.
> I think a simple but exaustive way to achieve this can be the direct mapping
> of the REST services described in
> http://sling.apache.org/site/managing-users-and-groups-jackrabbitusermanager.html
> and
> http://sling.apache.org/site/managing-permissions-jackrabbitaccessmanager.html,
> only using well-known JCR classes.
> For example, obtaining the users list could be as simple as getting the
> UserManager OSGI service and invoking a method like "public NodeIterator
> listUsers()", changing a permission could be achieved by getting the
> AccessManager OSGI service and invoking a method like "public void
> modifyPermission(String node_path, String principalId, String privilege_name,
> String privilege_value, String order)", and so on...
> Perhaps the best way to standardize these services is a dedicated API that
> formalizes the underlying concepts (ex: User, Group, Privilege and
> NodeAccessControl... if you think it's the case, i could propose my own...),
> but i think the simple REST services mapping could already be a nice (and
> ready-to-go) feature for developers...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
