Currently, the initialization logic for the component goes like this:
If cbo_auth_process exists in localstorage, fetch state from backend (GET /process call) => PROCESS_STATE
If PROCESS_STATE was loaded => update the component state based on PROCESS_STATE
Now, let's take a look at this example:
a user starts a signup and stops in passkey-append
he closes the tab and opens the component in a new tab
=> he will be put into the passkey-append state and he can not navigate back
=> this is a problem
[x] Refreshing a page in an ongoing process keeps the user at the current page and does NOT reset the process
[x] Aborting a process with back navigation still works
[x] Navigating to the component-url WITHOUT the hash loads the component in initial state and starts a new process
Implementation idea:
During initialization after step 1, we should compare the state that we get from the backend with the hashcode that we have in the frontend.
If the frontend hashcode does not match the current block returned by the backend, we should start a new process.
Why
Currently, the initialization logic for the component goes like this:
Now, let's take a look at this example:
What we want: If a user opens a new tab with https://component-url#passkey-append => show her the passkey-append screen => she can continue her process If a user opens a new tab with https://component-url#signup-init => load the component in initial state
Acceptance criteria
Implementation idea: During initialization after step 1, we should compare the state that we get from the backend with the hashcode that we have in the frontend. If the frontend hashcode does not match the current block returned by the backend, we should start a new process.