betodealmeida commented on PR #27631: URL: https://github.com/apache/superset/pull/27631#issuecomment-2026433961
@villebro I feel like you're asking me to solve a very specific problem you have — handling multiple OAuth providers for the same database type — with a solution that doesn't solve the problem I have. 🙃 I don't want my users to have to select an OAuth client when they add a database; I want it to just work for them with a standard client, so that everyone who adds Snowflake will have it automatically configured to use the Snowflake endpoint. At Preset, specifically, we don't want to store the client secret in the metadata database, because it creates a huge vector for attacks. If it gets exposed accidentally in the API it could lead to customers accessing resources from other customers, so we really need to have the secret stored in the config. So it would force us to have our clients creating their own OAuth applications, which is something that would be nice to have as optional, but not as a requirement. There is precedence for configs that can be overridden on a per-asset basis; `CACHE_DEFAULT_TIMEOUT` comes to mind, with a default value that can be overridden per database or dataset. So I don't the model of having a generic OAuth2 config is at odds with also having a client model — specially because for Snowflake, BigQuery, GSheets, Clickhouse, Dremio, the users will never have to specify a different client at the DB level, since there's always a single provider. -- 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: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
