fix(PN-15723): Handle user validation failure after token-exchange #1687
Conversation
AndreaCimini90
left a comment
AndreaCimini90
left a comment
There was a problem hiding this comment.
Remember to write the test case for this scenario.
Make the changes also for pg and pa
| @@ -0,0 +1,46 @@ | |||
| import * as React from 'react'; | |||
There was a problem hiding this comment.
Rename the file and function with FeedbackPage.
Remember to write test
| @@ -0,0 +1,26 @@ | |||
| /* eslint-disable functional/immutable-data */ | |||
There was a problem hiding this comment.
If userDataMatcher is used only in one place, we can avoid to create a new file and move the content into the file where we are using it
There was a problem hiding this comment.
userDataMatcher is used both in auth/reducers.ts and in auth/actions.ts
There was a problem hiding this comment.
You are right! Can you move this file under utility directory and rename it with user.utility.ts?
| title={getLocalizedOrDefaultLabel( | ||
| 'common', | ||
| 'user-validation-failed.title', | ||
| 'Validazione utente fallita' |
There was a problem hiding this comment.
remove the third parameter from the getLocalizedOrDefaultLabel
| } | ||
|
|
||
| export function adaptedTokenExchangeError(originalError: any) { | ||
| // validazione `user` TokenExchangeRequest fallisce |
There was a problem hiding this comment.
Write this in english
| isUnauthorizedUser: true, | ||
| response: { | ||
| ...originalError.response, | ||
| status: 499, |
There was a problem hiding this comment.
It's a non-standard client-defined HTTP status code, so it's available for custom application-level error handling.
| element={<AppNotAccessible onAssistanceClick={handleAssistanceClick} />} | ||
| element={<AppNotAccessible onAssistanceClick={handleGoToLandingSite} />} | ||
| /> | ||
| <Route |
There was a problem hiding this comment.
Maybe we can avoid to define another route and use the not_accessible one. Also in this case the app is not accessible. To distinguish between the two cases, you can pass a parameter (the error code can be enough) and do the logic inside the component.
In this way the UserValidationFailed component will be useless.
There was a problem hiding this comment.
I've refactored the code so that we now handle the two cases with two separate routes as before, both pointing to the same AppNotAccessible component (deleting UserValidationFailed) using a prop to distinguish them.
If you really meant using a single route for both cases I can update it and switch to a query-string parameter to discriminate between them. Just let me know which approach you prefer.
There was a problem hiding this comment.
I think that the single route is the best approach
| state.loading = false; | ||
| } | ||
| state.user = action.payload; | ||
| state.loading = false; |
There was a problem hiding this comment.
I should restore the sessionStorage.setItem('user', JSON.stringify(user)); code removing it from the sessionGuard
2 participants
Short description
This PR introduces error handling for the case when the user object returned from the token-exchange API fails schema validation.
Instead of silently redirect the user to the login page, we now display a dedicated page that informs the user about the validation failure. A new reusable ThankYouPage component has also been introduced following the design guidelines linked into the Jira issue.
How to test
This way you should be redirected to the "User validation failed" page