search

dermesser / yup-oauth2

An oauth2 client implementation providing the Device, Installed, Service Account, and several more flows.
https://docs.rs/yup-oauth2/
Apache License 2.0
219 stars 114 forks source link

API improvements for Flows #195

Closed elpiel closed 1 year ago

elpiel commented 1 year ago

I was looking into providing our own InstalledFlow, however, the InstalledFlow struct is not publicly exported and it's fields are pub(crate) and the same goes for token & new. This is not ideal, since, if you'd like to replace the DefaultInstalledFlowDelegate you cannot do it and in the documentation of InstalledFlow::token you have this line:

It's recommended not to use the DefaultInstalledFlowDelegate, but a specialized one. It is recommended but there is no way you can provide your own.

Right now, I don't see any good approach for providing the url to the user in an interface instead of the CLI println!

ggriffiniii commented 1 year ago

You want to create your own InstalledFlowDelegate (not InstalledFlow). Does the example here help?

elpiel commented 1 year ago

yes, actually it does. Somehow I missed this method in the builder.

I'm still not sure how this could be integrated in e.g. a webserver route to directly redirect and later redirect back the user to the same path. I might try implementing it and maybe adding example for that too.

dermesser commented 1 year ago

You're actually the second person in a short time (#191) to stumble over this, and even I didn't remember it at first sight. This clearly means that the documentation is lacking :) I will try to come up with some more explicit explanations around this somewhat unintuitive (at least for a Rust library) structure.

I'm still not sure how this could be integrated in e.g. a webserver route to directly redirect and later redirect back the user to the same path. I might try implementing it and maybe adding example for that too.

If you are working against an API using the "Installed Application Flow", it seems that this is your scenario (correct me if I'm wrong): https://developers.google.com/identity/protocols/oauth2/web-server#httprest_1

In that case, your server will obtain the authorization code through the callback that your user is redirected to by the provider. This will typically be an endpoint in the same server app or on some other server; right?

At that point it depends on your architecture how you get the code from the redirect URI back into your flow delegate. For example, if the redirect URI is handled by the same process, you might use some global "message broker" kind of architecture within the process allowing you to receive the code in the flow delegate.

Please let me know if I understood correctly what it is that you're stuck on!