[
https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525925#comment-17525925
]
Stefan Miklosovic edited comment on CASSANDRA-16456 at 4/21/22 6:19 PM:
------------------------------------------------------------------------
_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._
This in general makes sense, but as I look at it, when there is no
auth_provider, there is still PlainTextAuthProvider implicitly. That provider
is _default._ So even I do not have anything in cqlshrc in auth_provider,
imagine there still is one, the plaintext one. Hence it will see the stuff in
credentials file based in [PlainTextAuthProvider] section.
_It seems you want it to default to PlainTextAuthProvider in all cases when
auth provider isn't specified ..._
Exactly, yes, please.
_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._
Sorry, I am not getting this. I am not sure how it is done exactly on the code
level right at the moment but I would say that this should be pretty
transparent? Whatever properties there are specified in auth_provider, they are
taken into account and then they are eventually replaced by whatever is in
credentials. If there is a username property both in auth_provider section in
cqlshrc and in the related section in credentials, the property in credentials
overwrites / has precedence / shadows the one in cqlshrc.
was (Author: smiklosovic):
_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._
This in general makes sense, but as I look at it, when there is no
auth_provider, there is still PlainTextAuthProvider implicitly. That provider
is _default._ So even I do not have anything in cqlshrc in auth_provider,
imagine there still is one, the plaintext one. Hence it will see the stuff in
credentials file based in [PlainTextAuthProvider] section.
_It seems you want it to default to PlainTextAuthProvider in all cases when
auth provider isn't specified ..._
Exactly, yes, please.
> 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
