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.
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.
This removes the need for the remaining C interfaces.
Building any rust library with openssl adds a bunch
of depends such as foreign types via ffi and pkgconfg.
You are also required to have a prebuilt openssl.
Cross building and keeping up to date should be easier
with a pure rust implementation.
With Rust 1.15, proc macros have been stabilized. Therefore
custom build scripts are not required anymore.
This commit removes all the previous machinery and the
need for nightly.
serde_macros is no longer maintained and will eventually
fail on nightly.
Also in a hopefully not-so-distant future, we will be able
to use macros 1.1 in stable, and thus get rid of the
complication required for the hybrid approach.
This is a breaking change; it's supposed to fix#1. Also, it's a
proposal -- not sure if the benefits outweigh the cost of this.
The example/auth.rs binary is not broken by this, as it doesn't use the
API that changed. The tests have been updated accordingly.
As usage of the `!include` macro is enforced, there is currently no way
to use the exported macros from `yup_hyper_mock`. Now some more
boilerplate code was added to make it work anyway.
* Previously the meta-data was applied to the crate, which doesn't seem
to work.
* attempted to make `examples/auth.rs` work on stable. This isn't
properly tested now, as tests don't compile.
We are now at a state were stable as well as nightly work similarly,
but fail because `include!` doesn't behave correctly if macros are
involved. Namely it happens before crates are linked, yet it will
try to expand macros right away, which is a problem.
If the macro is defined in an empty fashion, it will actually be used
at include time, and expanded. Which causes issues further down the
compilation.
With the current 'fix' we manage to at least make everything but
`cargo test` work.
Related to #12
* It should help to keep track of how to properly call cargo in nightly
mode. After all, I have wasted some time, multiple times just trying
to figure out that I forgot to add the nightly feature.
* Slightly improved structure of lib.rs and includes
Related to #12
It doesn't yet work on nightly due to a panic in
https://goo.gl/RyM4GT
Might have something to do with me being on nightly,
and some cargo-related hickoup.
That way, we can pretty-print the respective application secret
strucures. This is primiarily of interest for the main client of this
library, namely Google APIs RS.
Version incremented.
Fixes#2
* Do not return massive custom result enums, but instead adhere to the
`Result` convention. This natively fixed our problem related to having
to make unnecessary clones, making our design much cleaner.
Fixes#4
