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

Reject old SDK versions at API #405

Open
nplasterer opened this issue Aug 15, 2024 · 5 comments
Open

Reject old SDK versions at API #405

nplasterer opened this issue Aug 15, 2024 · 5 comments
Labels
good first issue Good for newcomers

Comments

@nplasterer
Copy link
Contributor

libxmtp version in the header of requests. Force requests to be on a good version and reject all requests that aren't on that version.

@nplasterer
Copy link
Contributor Author

Client work knowing what version and storing it as a header
API work to take in those headers and reject the requests.

@insipx insipx added the good first issue Good for newcomers label Aug 28, 2024
@insipx
Copy link
Contributor

insipx commented Aug 28, 2024

The easiest way to accomplish this is to start properly versioning xmtp_mls, and then use the CARGO_VERSION environment variable: https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates.

This needs to be inserted into headers for requests in xmtp_api_grpc, (doc] and xmtp_api_http (doc)

We might want to pair that with a more official release process for libxmtp, probably a lightweight one for now while there is still lots of churn.

Should also consider whether we version our crates as one workspace, or version them separately by-crate. Probably, a workspace-wide version would work well -- this would ensure xmtp_mls, xmtp_api_grpc, and xmtp_api_http all have the same version. otherwise we could run into issues where we accidentally update the version in one place but not in another.

the sqlite-wasm backend could be versioned separately

@insipx
Copy link
Contributor

insipx commented Aug 29, 2024

done in xmtp/libxmtp#1011 Api part client part is finished

@insipx insipx closed this as completed Aug 29, 2024
@insipx insipx reopened this Aug 29, 2024
@nplasterer
Copy link
Contributor Author

What exactly needs to be done from the sdk side?

@insipx
Copy link
Contributor

insipx commented Sep 3, 2024

I don't think anything has to change for the SDKs, this should only be for libxmtp. I re-opened because I think this issue is also for changes to the go backend

@nplasterer nplasterer transferred this issue from xmtp/libxmtp Sep 12, 2024
@nplasterer nplasterer removed this from V3 Backlog Sep 12, 2024
@insipx insipx removed this from libxmtp Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants