-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for OAuth2 #189
Conversation
@jirijakes Great to see this! Indeed, we should support refresh tokens because it requires less interaction from the user, and leads to a better CLI experience. For JS, the build can be split into JVM and JS source files, like ZIO itself and many other ZIO projects. Let me know if you have any other questions! |
Good!
Thanks, John. |
@jirijakes Do you know when you might get a chance to push this through to completion?? |
I am progressing very slowly during the week, will have more time Friday to Sunday. I believe on Sunday, it could be ready. |
@jirijakes That's great, thanks for the update! |
Progress report
To make refreshing of token work seemlessly, I had to make access to access token effectful: trait OAuth2Token {
def refreshTokenNow: Task[Unit]
def accessToken: Task[AccessToken]
} With this, whenever JavaScriptThe biggest question I have now is what to do with JavaScript. Is the OAuth2 supposed to work with JS? I do have no experience with ScalaJS and when looking around ZIO projects, I could not find one that uses HTTP requests and file system. I found both should be possible with ScalaJS, however the lack of examples in ZIO ecosystem scares me a bit. Could I get an advice on this? Connected to this is a problem I had with splitting code into JS/JVM. Since What's missingBesides the JavaScript issue, a bit more documentation has to be added, error handling improved, remove a few Please, let me know if this approach is acceptable and which parts could be done better. |
I would not worry about that. Just make sure it compiles under both JVM and JS. if the OAuth is not available in JS, that's fine. Anyone interested in that feature could add it themselves down the road.
Put it into the common trait, just as yet another Options, alongside the existing ones; but push the implementation to a "support trait" which is implemented differently on JVM and JS. The JS implementation will just fail with an error indicating that OAuth is not yet supported on JS.
This is fine. 👍
This sounds like it will lead to a negative user experience. Whatever we do here, it should have the usability of, e.g. the Many users store keys in Thank you for your work on this feature! I think you are nearly there. |
Ready for review. Recent changes:
Not implemented:
|
Looks like there's a compiler crasher. Can you investigate and try to find a workaround? Usually working around Scala compiler's bugs is a matter of identifying the overall location and then experimenting until you find something that fixes it. To switch SBT to the version that's crashing in the CI, do |
zio-cli/js/src/main/scala/zio/cli/oauth2/OAuth2PlatformSpecific.scala
Outdated
Show resolved
Hide resolved
zio-cli/js/src/main/scala/zio/cli/oauth2/OAuth2PlatformSpecific.scala
Outdated
Show resolved
Hide resolved
zio-cli/jvm/src/main/scala/zio/cli/OptionsPlatformSpecific.scala
Outdated
Show resolved
Hide resolved
* @param expiresIn maximum period | ||
* @return the last response received before terminating | ||
*/ | ||
def pollingSchedule( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For things like this that we probably don't want to expose in the public API, be sure to mark private[cli]
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hid the whole class, it's not supposed to be accessible from outside.
val expiresAt = time.plus(response.expiresIn).withNano(0).toLocalTime() | ||
|
||
s"""| >> | ||
| >> Application requests to perform OAuth2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good help docs!
scope: List[String], | ||
auxiliaryOptions: Options[OAuth2AuxiliaryOptions] | ||
) extends Options[OAuth2Token] { | ||
override def helpDoc: HelpDoc = auxiliaryOptions.helpDoc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than delegating everything to auxiliaryOptions
, it may make sense to provide a bit of help here. But I suppose that depends on how it's rendered and if there is a good place to put help for a phantom options.
zio-cli/shared/src/main/scala/zio/cli/oauth2/OAuth2Provider.scala
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relatively minor changes, overall looks amazing!
I think we should look at improving help doc a bit: at the top-level help page, we should discuss the OAuth2 support. That will require traversing the options
in the CLIApp and seeieng if OAuth2Options
is somewhere there, and if so, documenting the feature.
Thanks for the review, John! I'll make the suggested changes.
It seems the cause is So in order to make this work in Java 8, there are two options, as I can see: either use built-in, archaic Can you please advise, what would be best in line with the project?
Yes, this makes sense. I will see what I can do. |
Let's bump JVM to 11 |
Reflected John's comments. I added help doc which appears when OAuth2 is used. See screenshot. I am not sure about wording and implementation (misusing
Shall I add it to this PR? Does it mean to remove Java 8 from ci.yml? zio-cli/.github/workflows/ci.yml Lines 59 to 62 in aadf2a4
|
Be sure that when --help is invoked, that no OAuth takes place, so that the user can see the help.
Yes, you modify the CI by making changes to the Github workflow. Instead of 8 we can just use 11. |
I think we should try to store the token in user home directory. Rather than the current directory. The reason is that the user may not have permission to modify the current directory, and also the user's current directory will keep changing all the time. You can get the home directory from Java properties: System.getProperty("user.home") |
Yup, verified.
Done.
Good idea. Done. |
Thank you for your work on this! |
Draft of OAuth2 support, which should utlimately resolve #187 and hopefully will allow me to /claim #187.
Current status:
???
, comments)TestsIssues:
Showcase: