You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2013/10/09 11:03:43 UTC

[jira] [Comment Edited] (SLING-3154) Add Topology Message Verification to the Discovery service.

    [ 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)