You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2020/02/13 22:20:17 UTC
[GitHub] [druid] himanshug edited a comment on issue #9351: Adding
CredentialsProvider, deprecating PasswordProvider
himanshug edited a comment on issue #9351: Adding CredentialsProvider, deprecating PasswordProvider
URL: https://github.com/apache/druid/issues/9351#issuecomment-585999965
coming back to peek into Druid PRs after a while and noticed this. Just wanted to let you know of https://github.com/apache/druid/issues/6666 which proposes something related for other reasons and it would be good to have that in mind as well.
Also, wouldn't
```
public interface CredentialsProvider
{
String getPassword(String key);
}
```
be more generic then which can handle more than two logically related secrets.
> Would you elaborate more on the example applications that require a password but not an account we should consider?
For DB , In all the places I used druid, username was never a secret . Also I see some passwords in https://druid.apache.org/docs/latest/development/extensions-core/druid-basic-security.html which don't necessarily need an "account". I am not saying that we need to keep `PasswordProvider` but just noting down the different use cases.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org