Simonas Kazlauskas d385601433 --all-features and --no-default-features
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.
2021-06-29 12:57:57 +03:00
2019-02-21 20:46:00 +00:00
2015-05-08 11:41:26 +02:00
2017-02-03 06:55:17 +01:00
2016-01-10 21:53:51 -05:00
2021-03-04 11:46:05 +01:00
2021-02-06 22:59:00 +11:00

Build
Status codecov crates.io

yup-oauth2 is a utility library which implements several OAuth 2.0 flows. It's mainly used by google-apis-rs, to authenticate against Google services. (However, you're able to use it with raw HTTP requests as well; the flows are implemented as token sources yielding HTTP Bearer tokens). Note that the newer, asynchronous versions of this crate (version 4) are not compatible with google-apis-rs anymore/at the moment.

To use asynchronous APIs with the new yup-oauth2 (from version 4), use the async-google-apis code generator, which generates asynchronous API stubs for Google APIs and other providers who provide Discovery documents for their REST APIs. (WARNING: that project is still alpha-quality. Contributions are welcome)

The provider we have been testing the code against is also Google. However, the code itself is generic, and any OAuth provider behaving like Google will work as well. If you find one that doesn't, please let us know and/or contribute a fix!

Supported authorization types

  • Device flow (user enters code on authorization page)
  • Installed application flow (user visits URL, copies code to application, application uses code to obtain token). Used for services like GMail, Drive, ...
  • Service account flow: Non-interactive authorization of server-to-server communication based on public key cryptography. Used for services like Cloud Pubsub, Cloud Storage, ...

Usage

Please have a look at the API landing page for all the examples you will ever need.

A simple commandline program which authenticates any scope and prints token information can be found in the examples directory.

The video below shows the auth example in action. It's meant to be used as utility to record all server communication and improve protocol compliance.

usage

Versions

  • Version 1.x for Hyper versions below 12
  • Version 2.x for Hyper versions 12 and above
  • Version 3.x for historical interest
  • Version 4.x for tokio 0.2/0.3
  • Version 5.x for tokio 1.0

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Description
No description provided
Readme 996 KiB
Languages
Rust 99.2%
Shell 0.8%