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