[
https://issues.apache.org/jira/browse/CALCITE-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270989#comment-17270989
]
Josh Elser commented on CALCITE-4469:
-------------------------------------
Heh, I was just thinking about this one this past week.
The original purpose behind not using "user" and "password" was that we passed
all configuration elements from Avatica down into the "real" JDBC driver inside
of the server. The "real" jdbc driver inside the Avatica server may be doing
its own authentication against the "real" database. This was the thinking where
Avatica is acting as a "trusted proxy" in front of the database.
However, there's another case to consider where Avatica should just pass along
the user credentials to the "real" JDBC driver.
I had tried to "handle" this way-back-when by just making Avatica have its own
properties for authentication. However, I think, like Istvan says, the common
case is either Avatica does the authentication itself _or_ Avatica passes the
authentication directly to the database. In either case, we can use user and
password.
> Accept standard JDBC user/password parameters
> ---------------------------------------------
>
> Key: CALCITE-4469
> URL: https://issues.apache.org/jira/browse/CALCITE-4469
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Istvan Toth
> Priority: Major
>
> Having to use avatica_user and avatica_password in the URL is pain point for
> new users.
> Accept the standard user and password parameters as aliases.
> This would also let users use the username/password fields in JDBC GUIs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
