[
https://issues.apache.org/jira/browse/CASSANDRA-21238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18066882#comment-18066882
]
Joel Shepherd commented on CASSANDRA-21238:
-------------------------------------------
This could be viewed as a configuration error, however in the context of CEP-50
it introduces a significant logical error. From a configuration standpoint:
{{authenticator: PasswordAuthenticator}}
... and ...
authenticator:
{{ class_name: PasswordAuthenticator}}
... both construct a ParameterizedClass using the
{{ParameterizedClass(String)}} constructor, which initializes parameters to an
empty map.
However, a typo like this:
authenticator:
{{ - class_name: PasswordAuthenticator}}
Causes SnakeYAML to create the ParameterizedClass using the default constructor
and reflection, resulting in {{parameters}} being {{{}null{}}}. This
configuration is attempting to set {{authenticator}} to a list of
ParameterizedClass objects (the sneaky '-' preceding class_name). SnakeYAML
apparently recognizes the mismatch, grabs the first list element and assigns it
instead. I don't know why the list element itself is instantiated differently
than it is with correct scalar config but it is.
(The issue affecting CEP-50 is that this comparison is being used to determine
if the default authenticator is already instantiated before attempting to
instantiate an instance for use in the negotiable authenticators list. Most
authenticators don't take well to being instantiated more than once, so we try
to avoid doing so. However, if ParameterizedClass.equals() fails to recognize
the authenticators are the same it can result in the authenticators list being
in a different order than as configured, which can lead to the negotiator
selecting a weaker authenticator than the administrator intended. E.g., the
administrator might prefer MutualTls, Password, AllowAll in that order. An
incorrect equals() result can wind up configuring the negotiator to use
MutualTls, AllowAll, Password instead: i.e, prefer AllowAll (no auth) to
password auth.
> Inconsistent parameters instantiation for ParameterizedClass
> ------------------------------------------------------------
>
> Key: CASSANDRA-21238
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21238
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Reporter: Joel Shepherd
> Priority: Normal
>
> Here is a partial repro. Consider two ways of declaring an authenticator in
> cassandra.yaml:
> authenticator: PasswordAuthenticator
> ... and ...
> authenticator:
> - class_name: PasswordAuthenticator
> Both will result in the successful instantiation of a PasswordAuthenticator,
> however the ParameterizedClass instances have different internal state. In
> the first form, the ParameterizedClass {{parameters}} member is an empty map.
> In the second form, it is {{{}null{}}}. This causes ParameterizedClass'
> {{equals()}} and {{hashCode()}} methods to exhibit inconsistent behavior.
> ParameterizedClass.{color:#172b4d}newInstance() forces a null {{parameters}}
> to an empty map, so most likely equals(), hashCode() and toString() should do
> the same since newInstance() will create an instance of the class identically
> in both cases.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
