Along with the public facing change the implementation has been modified
to no longer clone the scopes instead using the pointer to the scopes
the user provided. This greatly reduces the number of allocations on
each token() call.
Note that this also changes the hashing method used for token storage in
an incompatible way with the previous implementation. The previous
implementation pre-sorted the vector and hashed the contents to make the
result independent of the ordering of the scopes. Instead we now combine
the hash values of each scope together with XOR, thus producing a hash
value that does not depend on order without needing to allocate another
vector and sort.
Beyond simply moving to the builder pattern for intialization this has a
few other effects.
The DeviceFlow and InstalledFlow can no longer be used without an
associated Authenticator. This is becaus they no longer have any
publicly accessible constructor. All initialization goes through the
Authenticator. This also means that the flows are always initialized
with a clone of the hyper client used by the Authenticator.
The authenticator uses the builder pattern which allows omitting
optional fields. This means that if users simply want a default hyper
client, they don't need to create one explicitly. One will be created
automatically. If users want to specify a hyper client (maybe to allow
sharing a single client between different libraries) they can still do so
by using the hyper_client method on the builder. Additionally for both
AuthenticatorDelegate's and FlowDelegate's if the user does not specify
an override the default ones will be used.
The builders are now exposed publicly with the names of Authenicator,
InstalledFlow, and DeviceFlow. The structs that actually implement those
behaviors are now hidden and only expose the GetToken trait. This means
some methods that were previously publicly accessible are no longer
available, but the methods appeared to be implementation details that
probably shouldn't have been exposed anyway.
Specifying a port of zero has the server listen on an ephemeral port.
Many users may not be aware of that unless they have a background in
networking where that's common practice. I'm also not able to think of
any use cases where listening on a hardcoded port would be beneficial,
so with this change I've opted to remove the ability entirely rather
than simply documenting that almost everybody should specify zero.
Change it to accept an iterator of items that can be converted to
`String`s rather than an iterator of items that can be referenced as
`&str`s.
Primarily this allows it to be called with a larger variety of inputs.
For example ::std::env::args().skip(1) can now be passed directly to
token, where before it would first need to be collected into a vector.
Since all implementations unconditionally collected the iterator into a
vector this shouldn't have any negative impact on performance and should
actually reduce the number of allocations in some uses.
It simplifies the signature since the lifetime bounds are no longer
required.
This upgrade Hyper to v0.12 and updats to code to work for it. It has
being done with the minimum code change and so the logic is still
aukward for the futures model. This should be addressed in later commits
but I did not want to compilcate an already large commit.
For custom AuthenticatorDelegate implementations it may be very weird to
be required to return an additional character after the code from
present_user_url.
One may find himself chasing the bug which is bad UX for the user.
Improve this behavior and therefore introduce a breaking change that
will hopefully not break existing implementations nevertheless.
When implementing AuthenticatorDelegate one might want to change the
redirect_uri to use an authorized domain or just change the way
InstalledFlow works.
Add a redirect_uri method to AuthenticatorDelegate that may be
implemented to define a custom redirect uri if needed.
I mainly resolved some circular dependencies that had crept in, and
moved code around. I renamed helper.rs because that was not really an
appropriate name anymore, and moved the delegate code into a new module.
The "Installed App Flow" requires user interaction; we first generate a
URL that the user has to navigate to. Then, the user either pastes a
displayed code into the app being authorized, or the OAuth provider
redirects the user's browser to a webserver that is running on
localhost. This webserver is provided by the library and the flow should
work automatically. Extensive documentation can be found here:
https://developers.google.com/identity/protocols/OAuth2InstalledApp
An example for the InstalledFlow with the Drive API is here:
https://gist.github.com/dermesser/8c915ec4c88ee8e8927e7d40b276ca52
