[ https://issues.apache.org/jira/browse/GEODE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526012#comment-17526012 ]
ASF subversion and git services commented on GEODE-10243: --------------------------------------------------------- Commit 740d5e56758566146a1034f885197b742832c436 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=740d5e5675 ] GEODE-10243: Fail early if old client auth expires (#7603) * change the default "waitForReAuth" time to 60 seconds > Old clients with durable queues should fail early if > AuthenticationExpiredException is thrown > --------------------------------------------------------------------------------------------- > > Key: GEODE-10243 > URL: https://issues.apache.org/jira/browse/GEODE-10243 > Project: Geode > Issue Type: Improvement > Components: client queues > Reporter: Dan Smith > Assignee: Dan Smith > Priority: Major > Labels: pull-request-available > > As part of the changes for GEODE-9457, when an AuthenticationExpiredException > is thrown from the SecurityManager during message dispatching, we send a > message to 1.15 and newer clients asking them to re-authenticate. > For 1.14 and older clients, we do not send a message. Instead, we just wait > for the {color:#00875a}reauthenticate.wait.time{color} to elapse and then > close the connection. > The net effect of this is that if users are doing cache operations from 1.14 > and older clients, and their SecurityManager expires the credentials of the > old clients, they will sometimes see their clients re-authenticate themselves > in that time window. This will mislead users into thinking that > re-authentication works with old clients and client queues, even though we > [have documented that we don't support > it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35]. > Instead of allowing re-authentication to sometimes work in this unsupported > use case, we should always fail so that is clear to users that this use case > is not supported. -- This message was sent by Atlassian Jira (v8.20.7#820007)