curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-489) CreateOption.doProtected uses null protectedId when applied via AsyncCreateBuilderImpl
Date Wed, 05 Dec 2018 01:26:00 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16709498#comment-16709498
] 

ASF GitHub Bot commented on CURATOR-489:
----------------------------------------

Github user Randgalt commented on the issue:

    https://github.com/apache/curator/pull/284
  
    Actually - I just opened a PR on your repo with a test


> CreateOption.doProtected uses null protectedId when applied via AsyncCreateBuilderImpl
> --------------------------------------------------------------------------------------
>
>                 Key: CURATOR-489
>                 URL: https://issues.apache.org/jira/browse/CURATOR-489
>             Project: Apache Curator
>          Issue Type: Bug
>    Affects Versions: 4.0.1
>            Reporter: josh gruenberg
>            Assignee: Jordan Zimmerman
>            Priority: Major
>
> When trying to apply "protection" to an async node-creation with
>  {{CreateOption.doProtected}}, the protection is undermined because the node is created
with {{protectionId = null}}.
> The {{AsyncCreateBuilderImpl}} does pass {{doProtected = true}} to the {{CreateBuilderImpl}}
constructor. However, this constructor (incorrectly?) assigns {{protectedId = null}}, resulting
in a node-prefix of {{_c_null-}} (because {{getProtectedPrefix}} does not validate that the
provided {{protectedId}} is non-null). This entirely undermines the effectiveness of the protection.
> {code:java}
>     public CreateBuilderImpl(CuratorFrameworkImpl client, CreateMode createMode, Backgrounding
backgrounding, boolean createParentsIfNeeded, boolean createParentsAsContainers, boolean doProtected,
boolean compress, boolean setDataIfExists, List<ACL> aclList, Stat storingStat, long
ttl)
>     {
>         this.client = client;
>         this.createMode = createMode;
>         this.backgrounding = backgrounding;
>         this.createParentsIfNeeded = createParentsIfNeeded;
>         this.createParentsAsContainers = createParentsAsContainers;
>         this.doProtected = doProtected;
>         this.compress = compress;
>         this.setDataIfExists = setDataIfExists;
>         protectedId = null;                     // *** incorrect if doProtected?! ***
>         this.acling = new ACLing(client.getAclProvider(), aclList);
>         this.storingStat = storingStat;
>         this.ttl = ttl;
>     }
> {code}
> It looks to me as if that constructor should be assigning {{protectedId}} if {{doProtected}}
is true.
> I wonder if the {{doProtected}} field should just be eliminated in favor a method that
checks {{protectedId != null}}, to avoid this redundant encoding of intent?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message