Hi all,
I’ve run into a couple of issues while attempting to implement client-side user account linking in an Angular SPA, as described in this documentation page and this community FAQ. I appear to have run into an issue, and after looking through the Community posts, couldn’t find an answer.
As it stands, I have a local application where a user can click a button on their profile page to link another account to their own. This calls loginWithPopup
, then once the user logs in with that other account, I have access to the tokens of both of these accounts.
The trouble arrives at the next step, which is the front-end-driven merging of the two accounts’ user_metadata
objects. As the documentation and example repo stipulate, when I make a PATCH
call to /api/v2/users/[original account's sub value]
, I also pass in the header Authorization: Bearer [original account's access token]
. However, the request ends up having a different token entirely (not even the stored token I retrieved earlier from getIdTokenClaims()
), and as a result the PATCH
call fails with the error User to be acted on does not match subject in bearer token.
In addition to this, if I reload the page, the application now believes I’m logged in as this secondary user, not the one I was originally logged in as. It would seem that the loginWithPopup()
call to find the “other” account has overwritten the actual login, and I believe this also means that the AuthHttpInterceptor
is overwriting the Bearer token for my PATCH
call with one that matches the “new” account instead of the one to be merged into.
Is this an accurate understanding of the expected behaviour? If so, is there a way I can work around this structure in order to successfully link and combine accounts at the front end? For example, can I declare that a particular PATCH
call is to bypass the interceptor, or bypass specifically the changing of the Bearer token? I don’t think setting the interceptor to ignore calls to this endpoint will work, as there are other calls to the same endpoint (for mutating user_metadata
in other ways) which will rely on that interceptor working correctly.
Thanks for reading, and please let me know if I can provide any other context or information. As the code in question is for a business, I will need to seek approval to provide snippets of the current state, so if there’s a particular area or piece of configuration that will shine light, then I’ll aim to provide that. Cheers!