The `from_environment` function in
`ApplicationDefaultCredentialsAuthenticator` had an `unwrap` call on an
io::Result after reading the service account key from file. File
operations are inherently fallible, and panicking on such a failure is
generally a bad convention compared to propagating the IO error.
Propagating that error from the `from_environment` function is not
practical however, because the returned Result type does not include IO
errors, and changing the function signature would be semver
incompatible.
This change instead defers reading the key file to a later function
call. Now `from_environment` only reads the value of the
`GOOGLE_APPLICATION_CREDENTIALS` into a PathBuf, and a later call to
`ServiceAccountFlow::new` will actually read the file. That constructor
already returns an io::Result, so folding the read error into it is
possible, and none of the changes impact public items so it's all
semver-compatible.
This adjusts the code and documentation for `--all-features` and
`--no-default-features` to work correctly. With `--no-default-features`
no `DefaultAuthenticator` is made available. Users are in control of
picking the `Connector` they want to use, and are not forced to stomach
a dependency on `rustls` or `hyper-tls` if their TLS implementation of
choice doesn't happen to match one of the two.
To indicate this, the unstable `doc_cfg` feature is used to build
documentation on docs.rs. That way the generated documentation has
notices on these types that look as such:
> This is supported on crate features hyper-rustls or hyper-tls only.
Additionally this functionality is tested via additional coverage in the
Actions' CI.
By only allowing a custom storage. To use one of the built-in storage mechanism, there is already a special-purpose `persist_tokens_to_disk` method available.
Just pass `&[&str]` into custom storage providers. The scopeset struct has a range of unnecessary internal features.
It's now also part of the interface for custom storage providers that the given scopes will be both unique and sorted.
The only slightly awkward thing is that there's no conventient way to expose a `scopes_covered_by` helper method (which almost all custom storage engines will need), but it's still included in the example code.