[
https://issues.apache.org/jira/browse/SLING-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790170#comment-13790170
]
Stefan Egli edited comment on SLING-3154 at 10/9/13 9:03 AM:
-------------------------------------------------------------
I think we might be able to cover both aspects (the whitelist, and the
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the
API could be along the following lines:
{code:java}
public interface DiscoveryPayloadHandler {
public RequestEntity pack(String json);
public String unpack(SlingHttpServletRequest request) throws
RejectException;
}
{code}
Whereas pack() would be used in the TopologyConnectorClient before posting the
request, and unpack() would be used in the TopologyConnectorServlet when
handling the PUT/DELETE requests. Throwing of the RejectException would imply
ignoring/rejecting the request/announcement.
pack/unpack could be doing encrypt/decrypt/verify - but they could also do
things like gizp for example.
was (Author: egli):
I think we might be able to cover both aspects (the whitelist, and the
encrypt/decrypt) with one API - basically provide one hook to 'pack' a payload
for posting and one for 'unpacking' (and thus verifying) upon reception. Eg the
API could be along the following lines:
public interface DiscoveryPayloadHandler {
public RequestEntity pack(String json);
public String unpack(SlingHttpServletRequest request) throws
RejectException;
}
Whereas pack() would be used in the TopologyConnectorClient before posting the
request, and unpack() would be used in the TopologyConnectorServlet when
handling the PUT/DELETE requests. Throwing of the RejectException would imply
ignoring/rejecting the request/announcement.
pack/unpack could be doing encrypt/decrypt/verify - but they could also do
things like gizp for example.
> Add Topology Message Verification to the Discovery service.
> -----------------------------------------------------------
>
> Key: SLING-3154
> URL: https://issues.apache.org/jira/browse/SLING-3154
> Project: Sling
> Issue Type: Improvement
> Components: General
> Affects Versions: Discovery Impl 1.0.0
> Reporter: Ian Boston
> Assignee: Ian Boston
> Fix For: Discovery Impl 1.0.2
>
>
> The discovery service provides support for whitelisting sources of topology
> information, but in a cluster where the topology this creates a
> re-configuration load of order M*(n*(n-1)) where n is the number of nodes in
> the topology and M is the number of changes. That load rises rapidly as the
> number of changes and/or nodes increases.
> To address this there are 2 proposals.
> 1. To provide an SPI exported from the Discovery Impl bundle that allows
> implementors to implement whitelisting based on the request. This will need
> to support creating the request and validating the request.
> 2. Embed functionality within the Discovery Impl bundle that supports
> validation and encryption of topology requests.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
