geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-3249) Validate internal client/server messages
Date Wed, 23 Aug 2017 16:17:00 GMT


ASF subversion and git services commented on GEODE-3249:

Commit c8a365418fd185198b61113991e2947dc69d249e in geode's branch refs/heads/release/1.2.1
from [~bschuchardt]
[;h=c8a3654 ]

GEODE-3249: Validate internal client/server messages

This is a squashed commit of the following from feature/GEODE-3249b:

commit c16b151e57169733186f0c029d1957da32d59635
    "spotless" fixes

commit f8e7ddd5e4696907ce60a14f581ef1ca83e65232

    GEODE-3249: Validate internal client/server messages

    This was merely a matter of changing the server to require the credentials
    and changing the client to send credentials.  I removed the general overriding
    of AbstractOp.processSecureBytes() because it made no sense.  If the server
    sends a secure byte "part" in a message the client is obligated to process
    it or the next message it sends will cause a security violation.

    I've added a server-side property that folks can set to allow old clients
    to continue to work.  This must be used to roll the servers forward to the
    new version that contains this change.  Clients must then be rolled
    forward & the servers can then be rolled once again without the property set.

    The system property is

(cherry picked from commit 6be38cad729d56f355c7586ec994bfef933c5e65)

> Validate internal client/server messages
> ----------------------------------------
>                 Key: GEODE-3249
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: docs, messaging
>            Reporter: Anthony Baker
>            Assignee: Karen Smoler Miller
>             Fix For: 1.3.0, 1.2.1
> Some message types can not be invoked directly by an end user.  For validation purposes,
we should treat these messages the same way we treat normal messages.

This message was sent by Atlassian JIRA

View raw message