-
Notifications
You must be signed in to change notification settings - Fork 11
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
ADR 220 - Quests RPC Service login RFC #229
base: main
Are you sure you want to change the base?
Conversation
content/ADR-220-quests-rpc-login.md
Outdated
|
||
## Context, Reach & Prioritization | ||
|
||
The Quest RPC Service needs a way to validate who is the user that is requesting to connect to the service in order to know who is the user which is sending the events about a progress on a quest or trying to subscribe to quests' updates. The transport protocol for the service is WebSockets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Quest RPC Service needs a way to validate who is the user that is requesting to connect to the service in order to know who is the user which is sending the events about a progress on a quest or trying to subscribe to quests' updates. The transport protocol for the service is WebSockets. | |
The Quest RPC Service needs a way to validate who is the user that is requesting to connect to the service in order to identify who is sending the events about progress on a quest or trying to subscribe to quests' updates. The transport protocol for the service is WebSockets. |
content/ADR-220-quests-rpc-login.md
Outdated
|
||
## Specification | ||
|
||
The solution we proposed is to use the [Decentraland's AuthChain concept](https://docs.decentraland.org/contributor/auth/authchain/), [dcl-crypto](https://github.com/decentraland/decentraland-crypto-rust) crate, and a signature challenge after the connection upgrading. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The solution we proposed is to use the [Decentraland's AuthChain concept](https://docs.decentraland.org/contributor/auth/authchain/), [dcl-crypto](https://github.com/decentraland/decentraland-crypto-rust) crate, and a signature challenge after the connection upgrading. | |
The solution proposed in this document is to use the [Decentraland's AuthChain concept](https://docs.decentraland.org/contributor/auth/authchain/), [dcl-crypto](https://github.com/decentraland/decentraland-crypto-rust) crate, and a signature challenge after the connection upgrading. |
content/ADR-220-quests-rpc-login.md
Outdated
|
||
The solution we proposed is to use the [Decentraland's AuthChain concept](https://docs.decentraland.org/contributor/auth/authchain/), [dcl-crypto](https://github.com/decentraland/decentraland-crypto-rust) crate, and a signature challenge after the connection upgrading. | ||
|
||
Once the client opens the connection to the server, the server will sends the signature challenge which consists of a text message with a random unsigned 32-bit number ("signature_challenge_{random_u32}").Then, it will wait 30 seconds for the client to send a response back to the server. The response of the client must be the [AuthChain](https://docs.decentraland.org/contributor/auth/authchain/) containing the sent signature challenge signed. If 30 seconds elapse, the connection will be closed by the server or if the [AuthChain](https://docs.decentraland.org/contributor/auth/authchain/) signature or the message sent by the client is not a valid one, the connection will be also closed by the server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once the client opens the connection to the server, the server will sends the signature challenge which consists of a text message with a random unsigned 32-bit number ("signature_challenge_{random_u32}").Then, it will wait 30 seconds for the client to send a response back to the server. The response of the client must be the [AuthChain](https://docs.decentraland.org/contributor/auth/authchain/) containing the sent signature challenge signed. If 30 seconds elapse, the connection will be closed by the server or if the [AuthChain](https://docs.decentraland.org/contributor/auth/authchain/) signature or the message sent by the client is not a valid one, the connection will be also closed by the server. | |
Once the client opens the connection to the server, the server will send the signature challenge which consists of a text message with a random unsigned 32-bit number (`"signature_challenge_{random_u32}"`). Then, it will wait 30 seconds for the client to send a response back to the server. The client's response must be the [AuthChain](https://docs.decentraland.org/contributor/auth/authchain/) containing the signed sent signature challenge. If 30 seconds elapse without receiving the signature challenge or if the [AuthChain](https://docs.decentraland.org/contributor/auth/authchain/) signature of the message sent by the client is not a valid one, then the connection will be closed by the server. |
Deploying with Cloudflare Pages
|
This PR: - implements decentraland/adr#229 even though it could change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, maybe mixing two protocols over the same wire is dissonant with other implementations and maybe, may raise some problems in both ends (client&server) to stop handing the "auth protocol" to start using the "rpc" protocol.
Probably using an RpcAuthService.sendChallenge that either enables the rest of the services OR closes the connection may simplify things a lot
This PR adds an ADR about the authentication mechanism for Quest RPC Service