tolbertam commented on code in PR #3085:
URL: https://github.com/apache/cassandra/pull/3085#discussion_r1479199730
##########
src/java/org/apache/cassandra/auth/AuthenticatedUser.java:
##########
@@ -33,10 +35,10 @@
public class AuthenticatedUser
{
public static final String SYSTEM_USERNAME = "system";
- public static final AuthenticatedUser SYSTEM_USER = new
AuthenticatedUser(SYSTEM_USERNAME);
+ public static final AuthenticatedUser SYSTEM_USER = new
AuthenticatedUser(SYSTEM_USERNAME, SYSTEM_USERNAME);
Review Comment:
Just pushed
[605d9cb](https://github.com/apache/cassandra/pull/3085/commits/605d9cbaa047c79ba7f822a5c9c4ea915de7f269)
which includes `AuthenticationMode` enum in `IAuthenticator`.
It feels a bit weird that i'm converting the enum to a String in a number of
places, seems like it could be error prone and I feel like we're not getting
the full value of using an enum.
I had a few more possible ideas I'd throw out there to gauge your thoughts:
1. Add an enum value `CUSTOM` to `AuthenticationMode`, that 3rd party
implementors can use to indicate that the authentication mode used is something
'custom'. This would allow us to use `AuthenticationMode` all throughout the
API (without having to convert explicitly to String anywhere except maybe in
the system table). The main downside is that it's not very specific, but I
think for most implementors this would be sufficient as I don't expect an
implementor will support multiple custom modes in their authenticator.
2. Instead of using an enum, introduce a class for `AuthenticationMode` that
a third party could implement. I feel this one offers less value, and is only a
slight improvement over string.
option 1 isn't perfect but I think could be an improvement over what I just
implemented and will make the API cleaner and less error prone. What do you
think?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
