[
https://issues.jboss.org/browse/JGRP-1852?page=com.atlassian.jira.plugin....
]
Richard Achmatowicz edited comment on JGRP-1852 at 6/16/14 10:48 AM:
---------------------------------------------------------------------
Come to think of it, what happens if a number of clients have authenticated to the current
coordinator and then the coordinator changes? It would seem that any of the existing
server contexts pointing back to clients will not be present on the new coordinator. So
any attempt to support encryption will be impacted. Also, the wrap/unwrap style of
encryption used here seems to be based on point-to-point communication and not easily
extendible to multicast.
was (Author: rachmato):
Come to think of it, what happens if a number of clients have authenticated to the current
coordinator and then the coordinator changes? It would seem that any of the existing
server contexts pointing back to clients will not be present on the new coordinator.
SASL challenge-response cycle does not process challenges
---------------------------------------------------------
Key: JGRP-1852
URL:
https://issues.jboss.org/browse/JGRP-1852
Project: JGroups
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.5
Reporter: Richard Achmatowicz
Assignee: Tristan Tarrant
Fix For: 3.5
The SASL challenge-response cycle between a client peer and a server peer should look
like this:
* client sends (possibly empty) response
* server evaluates response and sends challenge
* client evaluates challenge and returns response
and so on until the cycle ends.
The client sends responses in SASL headers marked Type.RESPONSE.; the server sends
challenges in SASL headers marked Type.CHALLENGE.
Due to a typo, all headers are marked as Type.RESPONSE, so that CHALLENGE messages were
not being processed. The test case passes none the less!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)