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

Separate safe and unsafe RPC endpoints #3560

Closed
cwgoes opened this issue Feb 8, 2019 · 5 comments
Closed

Separate safe and unsafe RPC endpoints #3560

cwgoes opened this issue Feb 8, 2019 · 5 comments
Assignees

Comments

@cwgoes
Copy link
Contributor

cwgoes commented Feb 8, 2019

"Safe" endpoints can be publicly-exposed by a node to untrusted clients (modulo DoS).
"Unsafe" endpoints should not be publicly exposed to untrusted clients.

We also need a distinction for:

  • Routes where clients can verify the data returned by untrusted nodes with lite client proofs
  • Routes where clients cannot verify the data returned by untrusted nodes.
@cwgoes
Copy link
Contributor Author

cwgoes commented Feb 12, 2019

cc @cosmos/cosmos-ui Do you have any thoughts on this? It will probably change routes.

@jbibla
Copy link
Contributor

jbibla commented Feb 13, 2019

what will the authentication method look like for trusted clients?

@faboweb
Copy link
Contributor

faboweb commented Feb 13, 2019

Which endpoints would change? May also be a good chance to add missing endpoints to the REST server so we only have one source of truth.

@cwgoes
Copy link
Contributor Author

cwgoes commented Feb 13, 2019

what will the authentication method look like for trusted clients?

I don't know if we would have one initially; instead probably we'll just emphasize that untrusted RPC servers should only bind to localhost.

@alexanderbez
Copy link
Contributor

No longer needed due to #3641

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants