-
Notifications
You must be signed in to change notification settings - Fork 148
Various fixes/improvements #756
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -209,7 +209,7 @@ private AuthorizationResult getAuthorizationResultFromHttpListener() { | |
expirationTime = TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis()) + 1; | ||
} | ||
|
||
while (result == null && !interactiveRequest.futureReference().get().isCancelled()) { | ||
while (result == null && !interactiveRequest.futureReference().get().isDone()) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could you add a comment on what "isDone" is doing here? I think it returns true when cancel() is called, or when the future completes with success? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. isDone returns true when a future is cancelled (like the current behavior), plus when it completes normally or with an exception. In other words, By only checking |
||
if (TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis()) > expirationTime) { | ||
LOG.warn(String.format("Listener timed out after %S seconds, no authorization code was returned from the server during that time.", timeFromParameters)); | ||
break; | ||
|
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.
Timeout in interactive flow is not something MSALs do and it's not something we ask app dev to do either. It can take a really long time to perform auth - e.g. I was just asked to MFA and then to change password.
But anyway, it looks like this is based on public API, so it's fine.
Uh oh!
There was an error while loading. Please reload this page.
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 interactive flow we have a timeout parameter that would cause this loop to end after a default 120 seconds:
microsoft-authentication-library-for-java/msal4j-sdk/src/main/java/com/microsoft/aad/msal4j/InteractiveRequestParameters.java
Line 100 in ebdd4fc
This ended up being kind of a weird situation. In Java 8 there wasn't really a timeout option for ending a future (there was a timeout for waiting for the result), however in Java 9 they started introducing methods for completing the future after a timeout. Since we target Java 8 as a minimum but also want to support newer versions, this means
httpPollingTimeoutInSeconds
as a timeout to end the interactive flow