Allow passing custom AbortController to register and authenticate functions without breaking existing behavior

[hjaber]

Motivation

This Pull Request adds the ability to pass a custom AbortController to the register and authenticate functions. This allows finer control over the authentication lifecycle, which is helpful in applications that manage multiple authentication processes simultaneously or need to handle aborting operations in a specific way.

Changes Made

• Added an optional signal parameter to RegisterOptions and AuthenticateOptions interfaces.
• Modified the register and authenticate functions to use the provided signal if available.
• If a signal is provided in the options, it uses that AbortSignal.
• If no signal is provided, it falls back to using the existing global ongoingAuth logic.
• Maintained backward compatibility by preserving existing behavior when no signal is provided.
• Updated documentation and comments to reflect the new optional signal parameter.

Backward Compatibility

• Existing users who do not pass a signal will experience the same behavior as before.
• The global ongoingAuth variable is still used when no custom AbortController is provided.
• This change should not break any existing implementations.

Additional Notes

• It addresses issues where the global ongoingAuth could cause unintended side effects in complex applications.
• For simplicity and clarity, it's often better to let users manage their own AbortController instances. I am willing to submit a PR to remove the global controller altogether, but this would be a breaking change, so I have not done it here.

[dagnelies]

What exactly are you trying to achieve?

AFAIK this abord controller is only needed due to the weird passkeys autocomplete mechanism running in the background. This one needs to be cancelled if a registration must be performed instead.

[hjaber]

In my app, I first try passkey authentication with autocomplete, and if that doesn't work, I retry without it. The issue is that once I call authenticate() with autocomplete, I can't cancel that ongoing authentication process when I need to switch methods. This leads to errors like 'Cancel ongoing authentication' and leaves the authentication ceremony stuck.

By allowing an optional AbortSignal to be passed to the register and authenticate functions, I can have finer control over each authentication request. This lets me cancel specific authentication processes without interfering with others, especially when switching between different authentication methods based on user interaction.

The global AbortController currently in use doesn't allow this level of control, which causes problems in my app when managing multiple authentication flows.

[dagnelies]

Strange. This should work out of the box. Triggering the authentication should cancel any ongoing authentication and just work.

[hjaber]

Strange. This should work out of the box. Triggering the authentication should cancel any ongoing authentication and just work.

I made a attempt to reproduce the issue I'm facing. Once client.authenticate() is called with autocomplete true, I am unable to call client.authenticate() without autocomplete.

https://svelte.dev/playground/62b923e16dd84e48b040d12e1b3b1221?version=5.2.7

Svelte repl reproduction, for the demo to work it required logging in with github.

[dagnelies]

Regarding the authentication with autocomplete, it should be invoked during page load, or when the component is mounted. More precisely, everything must be ready before the user even focuses on the input field, otherwise it will not even be triggered. I guess I should describe that better in the docs.

Then, calling the second "manual" authenticate should make the "autocomplete" one running in the background fail with "Cancel ongoing authentication", and the current one proceed. I'll try to add this to the demo and clarify the docs ...when I have some time.