Skip to content

Conversation

@dominikhei
Copy link
Contributor


I haven't really found a standard way of how multiple auth types in connection are handled, but the Trino provider currently has some opaque behavior, is there an explanation why it is done this way?

currently:

  • password and jwt auth can be set at the same time, but password will be preferred
  • password and kerberos can't
  • password and cert can't
  • jwt and kerberos or cert can, but jwt will be preferred
  • kerberos and cert can, but kerberos will be preferred

I've simplified the logic so that only one authentication method may be specified per connection. If multiple are provided, an error is raised. This avoids silent misconfigurations and makes the behavior explicit and predictable. If someone thinks, that this is a bad idea and can explain me the rationale behind the current logic, please let me know :)

Question: Could this change be considered a bugfix? I’m hesitant to introduce a breaking change for this issue. If this is considered breaking, I would prefer enhancing logging instead, to clearly inform users which authentication type is actually used

@eladkal
Copy link
Contributor

eladkal commented Jul 10, 2025

Question: Could this change be considered a bugfix?

Yes but please add entry to the main of the change log explaining the details of the change for users. You can see examples in some of the providers change logs.

@dominikhei
Copy link
Contributor Author

Question: Could this change be considered a bugfix?

Yes but please add entry to the main of the change log explaining the details of the change for users. You can see examples in some of the providers change logs.

Just to clarify, should I add the entry under the latest release's 'Bug Fixes' section, or were you thinking of a separate note below the changelog, such that it will be included in the next release?

@eladkal
Copy link
Contributor

eladkal commented Jul 11, 2025

or were you thinking of a separate note below the changelog, such that it will be included in the next release?

That

@eladkal
Copy link
Contributor

eladkal commented Aug 4, 2025

@dominikhei can you rebase and resolve conflicts?

@dominikhei
Copy link
Contributor Author

@dominikhei can you rebase and resolve conflicts?

Thanks for the reminder, I was on holidays the last 2weeks. Will take care of it.

@eladkal eladkal merged commit 616be9e into apache:main Aug 5, 2025
75 checks passed
Nataneljpwd pushed a commit to Asquator/airflow that referenced this pull request Aug 5, 2025
…he TrinoHook (apache#53134)

* Added functionality to only allow one auth method simultaneously in the trino Hook

* Adjusted the changelog and logging structure of the hook incase of multiple auth types in the connection
HsiuChuanHsu pushed a commit to HsiuChuanHsu/airflow that referenced this pull request Aug 5, 2025
…he TrinoHook (apache#53134)

* Added functionality to only allow one auth method simultaneously in the trino Hook

* Adjusted the changelog and logging structure of the hook incase of multiple auth types in the connection
ferruzzi pushed a commit to aws-mwaa/upstream-to-airflow that referenced this pull request Aug 7, 2025
…he TrinoHook (apache#53134)

* Added functionality to only allow one auth method simultaneously in the trino Hook

* Adjusted the changelog and logging structure of the hook incase of multiple auth types in the connection
fweilun pushed a commit to fweilun/airflow that referenced this pull request Aug 11, 2025
…he TrinoHook (apache#53134)

* Added functionality to only allow one auth method simultaneously in the trino Hook

* Adjusted the changelog and logging structure of the hook incase of multiple auth types in the connection
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants