siddharthmittal13 opened a new issue, #716: URL: https://github.com/apache/arrow-rs-object-store/issues/716
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.** We need to access `gs://` paths using an explicit OAuth bearer token. Today, the normal GCS path goes through `object_store::parse_url_opts`. However, there does not appear to be a supported way to pass a bearer token through that standard option-parsing flow. Because of that, downstream users have to bypass the default path and manually construct a `GoogleCloudStorageBuilder` with a custom credential provider. The problem with that workaround is that it no longer preserves full behavior parity with the default `gs` handling. The manual builder path can forward recognized `GoogleConfigKey` options, but anything else handled by the standard `parse_url_opts` path may be lost or silently ignored. So the challenge is: we want bearer-token authentication for GCS without having to replace the default GCS option-handling path. **Describe the solution you'd like** A supported way to provide a GCS bearer token while still using the standard `parse_url_opts` flow. For example, one of these would solve the problem: - support a bearer-token option in the GCS parsing path - allow a credential override to be passed into the GCS builder/parser - provide a standard API for overriding credentials without bypassing the normal option handling The key requirement is that bearer-token auth should integrate with the existing `gs` option parsing instead of forcing downstream code into a custom builder path. **Describe alternatives you've considered** The alternative we considered was manually creating a `GoogleCloudStorageBuilder` and injecting a credential provider with the bearer token. That works for authentication, but it has downsides: - it bypasses `parse_url_opts` - it requires downstream code to reimplement part of the standard GCS setup - it may silently ignore extra options that would otherwise be handled by the default path So it works as a workaround, but not as a clean or robust long-term solution. **Additional context** This came up in a downstream integration where we added custom handling for a `google_bearer_token` option only for `gs://` URLs. That downstream implementation highlighted the API gap: once we switch to a custom builder to support bearer-token auth, we are no longer guaranteed to preserve all behavior from the default `parse_url_opts` path. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
