[
https://issues.apache.org/jira/browse/SLING-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13871890#comment-13871890
]
Bertrand Delacretaz commented on SLING-3315:
--------------------------------------------
I like the idea of using a Node to define who can access the configs, but note
that it ties you to JCR as opposed to Sling resources. I assume the replication
module is tied to JCR anyway so it's probably not a problem.
Could you add some logging to the isAuthorized method that checks
SECURITY_OBJECT, to expose how you implement access control? Activating DEBUG
logs should make it clear why a given request is authorized or not, and expose
the path of SECURITY_OBJECT so that people can understand by themselves how to
control access. Something like "granting access to agent configs as {} can read
/system/replication/security" might be good, where {} is the current request or
context.
Is all-or-nothing access to the replication configs ok, or do you need readonly
access in some cases? If the latter you could check more granular permissions
on /system/replication/security
Looking at logging calls you are often logging the agent's name, would it be
better to just rely on the agent's toString() method to provide the identity of
the agent, and use just the agent object in logging?
> Refactor replication HTTP API
> -----------------------------
>
> Key: SLING-3315
> URL: https://issues.apache.org/jira/browse/SLING-3315
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Reporter: Marius Petria
> Labels: replication
> Attachments: SLING-3315.1.patch, SLING-3315.patch
>
>
> Refactor HTTP API in order to access independently the configuration of an
> agent and the service API for an agent. This was needed because there are
> times when a configuration can exist without an agent being available (e.g.
> when the agent is not disabled).
> Proposed API:
> Managing configuration
> POST /system/replication/config/agent (creates and agent cofig)
> GET /system/replication/config/agent (retrieves all agents config)
> POST /system/replication/config/agent/{agentName} (updates and agent)
> GET /system/replication/config/agent/{agentName} (retrieves the agent
> config)
> DELETE /system/replication/config/agent/{agentName} (deletes an agent config)
> Managing agent
> POST /system/replication/config/agent/{agentName} (schedules a package
> for replication or removes one from the queue)
> GET /system/replication/config/agent/{agentName}/queue (lists the
> packages in the queue)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
