Skip to content

Conversation

@artonge
Copy link

@artonge artonge commented Nov 6, 2024

We are migrating to in-request password confirmation, so it makes sens to have all that logic in this repository.

Most of the code is a copy-past from the @nc/password-confirmation repository.

Then there is the addition of a new interceptor to use the pwd confirmation logic.

@artonge artonge self-assigned this Nov 6, 2024
@artonge artonge requested a review from susnux November 6, 2024 16:48
@artonge artonge added the enhancement New feature or request label Nov 6, 2024
We are migrating to in-request password confirmation, so it makes sens to have all that logic in this repository.

Most of the code is a copy-past from the `@nc/password-confirmation` repository.

Then there is the addition of a new interceptor to use the pwd confirmation logic.

Signed-off-by: Louis Chemineau <[email protected]>
@artonge artonge force-pushed the artonge/bundle_pwd_confirmation branch from f170450 to cdb1c48 Compare November 6, 2024 17:31
Copy link
Contributor

@susnux susnux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice work!
One thing about the interceptors: I do not really see the use case of the id you use on the requests (and the maps).
Because you can simply await either the confirmation or the dialog response.

And for the case of multiple requests with authentication (could happen if you put the request in async functions), we should simply delay those requests until the current confirmation is done.
This is especially for UX, as otherwise multiple dialogs could stack over each other.
With the current approach multiple different password confirmations could stack, even if the first would unblock.
E.g.:

  1. request A with lax confirmation
  2. A dialog is shown, request to confirm is sent
  3. request B with lax confirmation
  4. B dialog is shown
  5. A resolves successfully
  6. B sends the request again

Instead B should be waited until A is fully done, then in this case no confirmation is even needed for B.

// theFileYouDeclaredTheCustomConfigIn.ts
declare module 'axios' {
export interface AxiosRequestConfig {
confirmPassword?: 'reminder'|'inRequest';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the name a bit confusing, how about strict and lax?
Just personal opinion, so feel free to ignore and mark as resolve.

import { onError as onCsrfTokenError } from './interceptors/csrf-token'
import { onError as onMaintenanceModeError } from './interceptors/maintenance-mode'
import { onError as onNotLoggedInError } from './interceptors/not-logged-in'
import { addPasswordConfirmationInterceptors } from './password-confirmation'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should also export this function? Might be useful if a custom Axios instance is created.

@artonge
Copy link
Author

artonge commented Nov 13, 2024

@artonge artonge closed this Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants