apache / apache/arrow-rs-object-store

GoogleCloudStorageBuilder `with_skip_signature(true)` still attempting to fetch credentials

Open
#520 1 comment 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.