You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by "tustvold (via GitHub)" <gi...@apache.org> on 2023/05/17 20:12:16 UTC
[GitHub] [arrow-rs] tustvold opened a new issue, #4240: Return Error on Conflicting Credential Configuration
tustvold opened a new issue, #4240:
URL: https://github.com/apache/arrow-rs/issues/4240
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**
<!--
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
(This section helps Arrow developers understand the context and *why* for this feature, in addition to the *what*)
-->
Comment from @alamb on https://github.com/apache/arrow-rs/pull/4235/files#r1196996290 suggested erroring if an object_store is constructed with multiple conflicting credentials. This is consistent with the behaviour of tools like AWS SDK, but may not be desirable in all cases. Creating an issue to solicit thoughts.
**Describe the solution you'd like**
<!--
A clear and concise description of what you want to happen.
-->
I'm honestly not sure, but I think we should probably either do nothing or return an error.
**Describe alternatives you've considered**
<!--
A clear and concise description of any alternative solutions or features you've considered.
-->
**Additional context**
<!--
Add any other context or screenshots about the feature request here.
-->
--
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: github-unsubscribe@arrow.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-rs] roeap commented on issue #4240: Return Error on Conflicting Credential Configuration
Posted by "roeap (via GitHub)" <gi...@apache.org>.
roeap commented on issue #4240:
URL: https://github.com/apache/arrow-rs/issues/4240#issuecomment-1552913838
The way to go is maybe to keep the augmentation logic as a separate step, and not make it part of the builders itself. In test scenarios One would create a specific store instance via the builder, and may choose the have a config helper that augments from the env as a pre-processing step for the config before it gets passed into the builder.
Obviously that only works for the config API. Erroring in an ambiguous case - especially in the builder - seems very reasonable to me.
--
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: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-rs] roeap commented on issue #4240: Return Error on Conflicting Credential Configuration
Posted by "roeap (via GitHub)" <gi...@apache.org>.
roeap commented on issue #4240:
URL: https://github.com/apache/arrow-rs/issues/4240#issuecomment-1552825834
I played around a little bit with how robust config handling might look like. Guessing the users intent from the passed configuration remains challenging, but I did come up with a [rough draft](https://github.com/delta-io/delta-rs/pull/1378) of something that "might" eventually work.
The main idea is to provide a priority of credentials and the required configuration keys to construct a specific credential. Then so far doing several passes through the priority list.
- If the passed options contain a full credential we use that one.
- If the passed options contain some config for a credential, and we can augment the rest from the environment, we choose that.
- If we can parse a full credential from then env, we choose it.
- Else we fall back to config free credentials (i.e. metadata endpoints)
I was also thinking about having some notions of "tells" - e.g. for azure if a client secret is provided, we assume the user intents to use client secret auth, and error if we cannot find client and authority id ...
As mentioned, this is so far just a rough draft, but if you think this might lead somewhere I'd be happy to move the PR over here...
--
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: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [arrow-rs] alamb commented on issue #4240: Return Error on Conflicting Credential Configuration
Posted by "alamb (via GitHub)" <gi...@apache.org>.
alamb commented on issue #4240:
URL: https://github.com/apache/arrow-rs/issues/4240#issuecomment-1552864940
Another reason that erroring might be preferable could be something like trying to configure your tool for a development environment by passing development credentials, but doing so in a shell or something that had production credentials as well.
In this case as as user I would definitely want an error rather than accidentally accessing the production systme
--
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: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org