You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 28, 2020. It is now read-only.
Apps that are meant to be hosted in a subdomain of Lastuser (such as *.hasgeek.com) will inherit the session cookie from the parent domain, but may not necessarily have that user registered already. While they can query Lastuser for user details, such a query does not go through the auth workflow required to get a token with the necessary scope.
Lastuser needs a new mechanism, similar to the current trusted client flag, where such apps have their scope defined in the client record, and have automatic access to that scope for all users, without specific authorization for each user.
The mechanism could either be (a) via an API endpoint that generates a user token on demand, or (b) removes the need for tokens entirely, using client credentials alone, so that there is no need for additional database storage. This will let client apps remove the User table entirely and just store UUID foreign keys with constraint validation in the app layer.
The text was updated successfully, but these errors were encountered:
The implementation in 084944b uses approach A: generates a token on demand. It does not remove the need for tokens. This means clients must still store tokens.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Apps that are meant to be hosted in a subdomain of Lastuser (such as *.hasgeek.com) will inherit the session cookie from the parent domain, but may not necessarily have that user registered already. While they can query Lastuser for user details, such a query does not go through the auth workflow required to get a token with the necessary scope.
Lastuser needs a new mechanism, similar to the current trusted client flag, where such apps have their scope defined in the client record, and have automatic access to that scope for all users, without specific authorization for each user.
The mechanism could either be (a) via an API endpoint that generates a user token on demand, or (b) removes the need for tokens entirely, using client credentials alone, so that there is no need for additional database storage. This will let client apps remove the User table entirely and just store UUID foreign keys with constraint validation in the app layer.
The text was updated successfully, but these errors were encountered: