[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525830#comment-17525830 ]
Brian Houser commented on CASSANDRA-16456: ------------------------------------------ Thanks for the notes I'll update the code. Hmm ok let me explain my thinking.... Cqlsh.py is in charge of parsing stuff at the command line level, and processing the legacy authentication section. >From this it gets a user name and password. At this point my thinking was >that it should work exactly as it did before: * if there is a username, but no password, it should prompt for a password. * If there is no username, no password and no auth_provider, it should just use None for auth provider * If there is a username and a password, it should use it directly. If you are specifying a new AuthProvider (that is something that isn't PlainTextAuthProvider) than the convention is very simple... * Get the module and class name form the auth_provider section of the cqlshrc file * Get additional properties from any properties left in [auth_provider]section of the cqlshrc file * Get additional properties from everything in the credentials section labeled with the auth_provider class name. For example... If I am using the FooAuthProvider... my cqlshrc file would look like this... ``` [auth_provider] module = foo.foo classname = FooAuthProvider prop1 = value1 ``` My credentials file might look like this... ``` [FooAuthProvider] prop2= value2 ``` FooAuthProvider would get called with the name prop1, prop2. Notice that if there is no auth_provider section in cqlshrc file specifying what you want to load... the credentials file won't find any properties. You need to specify an auth_provider to use the "new school" way of loading the credentials file. The whole intent of specifying the auth provider name in the credentials file seemed to be to allow there to be different credentials in one place depending on the auth provider specified. In keeping with python convention, I was trying to force you to be specific if you were going to use the new way of loading stuff... since this is meant for custom loading of auth providers. There's already a legacy case for authentication section, specifying the username on the command line. It seems you want it to default to PlainTextAuthProvider in all cases when auth provider isn't specified, I can do that pretty easily in the Authhandling bit. In which case, if you don't specify any provider in the cqlshrc file, I'll assume you meant PlainTextAuthProvider, and pull it from the credentials file if it exists and no other auth_provider is specified. I appreciate that you provided a fix for your concern, but unfortunately it's easy to see this creating a clash with newer providers. If a provider happens to use a property called 'username' with the fix you propose, I'll end up loading the plaintextauth provider instead of the one specified, which would be pretty confusing. I'd rather shove any new logic into the authhandling piece where it can be unit tested more easily. > Add Plugin Support for CQLSH > ---------------------------- > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh > Reporter: Brian Houser > Assignee: Brian Houser > Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.7#820007) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org