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
This would be a nice thing to have since it would allow for other servers to use the same login system while blocking modifications to the official api's database.
Scopes
An example of a scope would be user.read and account.read, the first would allow for the server to check if an user exists or not, and the second would allow for a server to verify the password of an existing account, if found.
server.self.update would allow a server to update its own metadata. discord.link.write would allow a server to initiate a discord linking process with the official api's application. account.write would allow a server to create new accounts.
Any official (trusted) servers would be given an token with all scopes, while servers which are administered by members would be given access on a per-need basis, with those servers holding an local database which will not sync with the global source of truth for the functionality they aren't authorized.
The status of each request not being synced with the global source of truth must be notified to the end user, in order to minimize confusion.
Reasoning
This would allow for a wider gamut of possible play styles to be displayed.
Ephemeral event servers could also be a part of this.
A team responsible for maintaining the integrations for the required versions of the servers, when enough activity is found would be needed.
Carefulness must be taken for this to not be exploited. Session Transferring would be behind a scope, and only allowed between trusted servers which both have the session.transfer scope, and that scope would require session.create and session.destroy scopes.
Re-utilizing the same token in different servers would immediately invalidate the token being used. Two different servers must never have the same token.
Tokens would also expire after a set period and need to be refreshed. Only a single refresh would be allowed per token, and the scopes provided must match exactly the original request.
The text was updated successfully, but these errors were encountered:
This is blocked behind the migration to sqlite. After that is done and the new system is tested in production we can start handling scopes and a re-structuring of the api permission system.
This would be a nice thing to have since it would allow for other servers to use the same login system while blocking modifications to the official api's database.
Scopes
An example of a scope would be
user.read
andaccount.read
, the first would allow for the server to check if an user exists or not, and the second would allow for a server to verify the password of an existing account, if found.server.self.update
would allow a server to update its own metadata.discord.link.write
would allow a server to initiate a discord linking process with the official api's application.account.write
would allow a server to create new accounts.Any official (trusted) servers would be given an token with all scopes, while servers which are administered by members would be given access on a per-need basis, with those servers holding an local database which
will not
sync with the global source of truth for the functionality they aren't authorized.The status of each request not being synced with the global source of truth must be notified to the end user, in order to minimize confusion.
Reasoning
This would allow for a wider gamut of possible play styles to be displayed.
Ephemeral event servers could also be a part of this.
A team responsible for maintaining the integrations for the required versions of the servers, when enough activity is found would be needed.
Carefulness must be taken for this to not be exploited. Session Transferring would be behind a scope, and only allowed between trusted servers which both have the
session.transfer
scope, and that scope would requiresession.create
andsession.destroy
scopes.Re-utilizing the same token in different servers would immediately invalidate the token being used. Two different servers
must
never have the same token.Tokens would also expire after a set period and need to be refreshed. Only a single refresh would be allowed per token, and the scopes provided must match exactly the original request.
The text was updated successfully, but these errors were encountered: