-
Notifications
You must be signed in to change notification settings - Fork 3
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
Disable token authentication for API v3 publishes #286
Conversation
I like the idea of jumping straight from version 0 to version 3. Our versioning is confusing enough without introducing new numbers. |
pkg/api/interceptor.go
Outdated
func (wa *WalletAuthorizer) requiresAuthorization(req interface{}) bool { | ||
_, isPublish := req.(*messagev1.PublishRequest) | ||
return isPublish | ||
return isPublish && !wa.isApiVersion1(req.(*messagev1.PublishRequest)) |
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.
I'd be inclined to only turn this off in the dev
environment. To do that we could just have an environment variable and a configuration flag disableV3Auth
or something, and only set it to true
in the dev environment.
This PR: - Defaults the CLI to use the XMTP dev network - Adds a `--local` option for pointing to localhost instead - Use `/xmtp/3` endpoints instead of `/xmtp/1` endpoints for consistency with client versioning - Adds detail to networking errors This means that external consumers don't have to run a local node in order to run the CLI, and it means the CLI can be tested across multiple machines. Will land xmtp/xmtp-node-go#286 and verify that the dev network accepts CLI requests before landing this.
The next version of the protocol will no longer use identity keys, and instead uses installation keys. Installation keys are also of a different format (Ed25519 + Curve25519) vs identity keys (secp256k1). We can temporarily disable authentication for
V1V3 publishes during development.Regarding API versioning - what are our thoughts on naming this API version 3, instead of 1, to align with the client versioning?