Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Local) UserService ID resolution #559

Open
sei-bstein opened this issue Dec 4, 2024 · 0 comments
Open

(Local) UserService ID resolution #559

sei-bstein opened this issue Dec 4, 2024 · 0 comments
Assignees
Labels
bug: non-breaking Issues that aren't desirable but don't directly impact app behavior. chores Keeping our project tidy, current, and building

Comments

@sei-bstein
Copy link
Contributor

There are some interesting quirks in the relationship between the web client's auth.service and its user.service (the one in the Utility module). The auth service basically sits on top of the OIDC library, and its responsibility more or less ends there. The user service relates the oidc profile to a Gameboard user. Due to the rxjs-ey way the user service is implemented, it can have an undefined value for the current user while the auth service's OIDC profile does indeed have a valid subject claim. This results in an odd situation where a check for a valid token and subject returns the expected value, but the user service's current user is undefined. This caused a bug in one of the guards, as at the time it gets evaluated on page reload, it doesn't have the user it needs (see here, where we had to work around by checking the auth service's claim instead).

Ultimately, I think exposing the auth service separately isn't that useful anyway. Ideally we'd rework these into a common service that has more stable behavior, but we're working around for now, and I don't think it's a massive architectural liability for now.

@sei-bstein sei-bstein added chores Keeping our project tidy, current, and building bug: non-breaking Issues that aren't desirable but don't directly impact app behavior. labels Dec 4, 2024
@sei-bstein sei-bstein self-assigned this Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug: non-breaking Issues that aren't desirable but don't directly impact app behavior. chores Keeping our project tidy, current, and building
Projects
None yet
Development

No branches or pull requests

1 participant