apache / apache/arrow-rs-object-store
GoogleCloudStorageBuilder `with_skip_signature(true)` still attempting to fetch credentials
- Dominant language
- Rust
- Stars
- 322
- Forks
- 212
- Avg merge
- 5d 2h
- Merged PRs (30d)
- 10
Description
**Describe the bug**
I have created a GcsStore with a custom HTTP connector and `with_skip_signature(true)`. It was modeled after this gist: https://gist.github.com/alvarowolfx/fac50c9f2c0e08f1c0a0dd6eb4f8630e
My goal was to use very customized logic to fetch credentials and add them as a Bearer token.
[The docs say this](https://docs.rs/object_store/0.12.4/object_store/gcp/struct.GoogleCloudStorageBuilder.html#method.with_skip_signature) about with_skip_signature:
> If enabled, [GoogleCloudStorage](https://docs.rs/object_store/0.12.4/object_store/gcp/struct.GoogleCloudStorage.html) **will not fetch credentials** and will not sign requests.
(emphasis added)
Despite this, I am observing that when using `GoogleCloudStorageBuilder` in this manner, it is attempting to fetch credentials. For example, if I delete `~/.config/gcloud/application_default_credentials.json` entirely, then I observe object_store trying and failing to fetch a token from the instance metadata service. Here is a sample log from my custom http connector (note that this is not the exact same code as the gist I linked, just similar).
```
2025-10-28T16:35:05.026635Z TRACE libdisget::store::google_auth_connector: Sending request, req: Request { method: GET, uri: http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token?audience=https%3A%2F%2Fwww.googleapis.com%2Foauth2%2Fv4%2Ftoken, version: HTTP/1.1, headers: {"metadata-flavor": "Google", "authorization": "Bearer "}, body: HttpRequestBody(Bytes(b"")) }
at discord_disget/libdisget/src/store/google_auth_connector.rs:117
```
The bearer token is getting attached in my HttpConnector as per the gist, which is why it is nonsensically (and somewhat ironically) in this request. Anyways, since this is on my local macbook these requests of course fail, and eventually cause the entire operation to fail.
If `~/.config/gcloud/application_default_credentials.json`, _does_ exist, then I observe object_store attempting to use that to refresh the credentials. This might succeed, or might fail, if the credentials are invalid/expired. This is how i first detected this issue - object_store was attempting to use the embedded refresh token to fetch a fresh access token, but this was failing.
So it seems that even when `.with_skip_signature(true)`, object_store is still running through its standard credential fetching routine.
**To Reproduce**
Use a HttpConnector + `.with_skip_signature(true)` as per the linked gist. Add extra logs, and observe that object_store is attempting to retrieve credentials using its own logic.
**Expected behavior**
The documented behavior - object store does not attempt to retrieve credentials when using `.with_skip_signature(true)`.
**Additional context**
We are using object_store in a developer-facing CLI tool. We have a very particular and customized priority order for different credential strategies to try which are more suited to the idiosyncrasies and variations in our development environments. This is why we are not using the built in credential fetching from object_store.
I am using object_store version `0.12.3`
Contributor guide
Research direction
Start at GoogleCloudStorageBuilder::with_skip_signature and reproduce the issue with a custom HttpConnector, as described, while logging credential requests. Trace the Google Cloud Storage credential-fetching path and verify that enabling skip_signature avoids credential retrieval and request signing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- google-cloud, rust
- Domain
- cloud
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100