Add optional callback parameter to authorize(), fired before the redirect occurs.

[krashanoff]

I would have made an issue for this, but the code change is so small that I think it's harmless to leave it as a PR. I made the change as short as possible without disrupting existing convention (though my use of ?.() is the first in the repo).

Changes

Adds an optional callback field to the public API of WebAuth.authorize such that developers can call some extra JavaScript before the user is redirected to the Auth0 login flow. i.e., the signature of authorize is now:

WebAuth.prototype.authorize = function (options, cb) {
  // ...
}

This solves an extremely specific issue that I encountered using a stateful SPA with the Auth0 JS SDK. For example, consider a React app wants to log in the user, display some loading state or play some animation before that happens, but set the page state to not display that animation just before the user is redirected.

While this risks some amount of content flash, it prevents certain browsers from hanging onto the incorrect state. The issue I was encountering, in particular, is that when the user presses their browser's back button, the browser held onto the last state, and would incorrectly keep said animation playing, or the loading state enabled.

I have tried using a few other methods to get the page state to "reset" before redirection, e.g. https://github.com/streamich/react-use/blob/master/docs/useUnmount.md or onbeforeunload, but the React method is unpredictable, and running JavaScript before redirection is fairly unpredictable across browsers.

Perhaps there's an easier way of solving this problem that I missed? Any input is appreciated.

References

N/A

Testing

• This change adds unit test coverage
• This change adds integration test coverage

Checklist

• I have read the Auth0 general contribution guidelines
• I have read the Auth0 Code of Conduct
• All tests and linters described in the Develop section run without errors

[nandan-bhat]

Hi @krashanoff,

Could you provide further details on when you intend to initiate the animation or loading state? It appears that the callback changes are applied sequentially and are triggered immediately. Usually we use callbacks to handle asynchronous scenarios.

Regarding alternative approaches, have you explored utilizing window-level events to manage the application state? For instance, you could consider utilizing the beforeunload event or other relevant events to detect redirects.

Furthermore, considering the WebAuth.popup member, which offers a callback via WebAuth.popup.authorize(options, cb) [Documentation], in this case cb is an error handler callback. Implementing a callback in webAuthInstance.authorize() with distinct behavior from WebAuth.popup.authorize(options, cb) could potentially lead to confusion.

@frederikprijck , @gyaneshgouraw-okta what's your opinion on this ?

[frederikprijck]

I agree. I dont think a callback as done here makes sense as it indicates asynchronity, while there isnt.

This isnt much different than putting the code directly before calling authorize, so I would recommend sticking with that (unless I am missing something)

[krashanoff]

Could you provide further details on when you intend to initiate the animation or loading state? It appears that the callback changes are applied sequentially and are triggered immediately. Usually we use callbacks to handle asynchronous scenarios.

Regarding alternative approaches, have you explored utilizing window-level events to manage the application state? For instance, you could consider utilizing the beforeunload event or other relevant events to detect redirects.

In my use case, the intent was to just ensure that the change in animation state is, as close as possible, "the last thing the browser sees" before navigating away, without resorting to adding a beforeunload or similar to the page. Separately, beforeunload has some browser-specific gotchas that I was attempting to avoid (https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event#usage_notes). I might be misreading, but wouldn't the redirect initiated from Auth0 would be considered not to be user-initiated on most platforms?

This isnt much different than putting the code directly before calling authorize, so I would recommend sticking with that (unless I am missing something)

You would be exactly right, hah. The goal here was to just get a synchronous state update as close as possible to where the redirect is performed. So admittedly, this is a silly, selfish change.

---

In any case, it seems like one thing I did get wrong was the convention for callbacks in the project. I did notice that callbacks in other functions are used for error handling, but didn't think much of it when adding a function parameter named cb.

I'll find an escape hatch without patching the library, or otherwise maintain this patch out of band. Just wanted to float the idea to see if there was any opinion on this. Thanks for the time!