POST license API endpoint #3570
Conversation
Signed-off-by: Spike Curtis <spike@coder.com>
Signed-off-by: Spike Curtis <spike@coder.com>
Signed-off-by: Spike Curtis <spike@coder.com>
Signed-off-by: Spike Curtis <spike@coder.com>
Signed-off-by: Spike Curtis <spike@coder.com>
| //go:embed keys/2022-08-12 | ||
| var key20220812 []byte | ||
|
|
||
| var keys = map[string]ed25519.PublicKey{"2022-08-12": ed25519.PublicKey(key20220812)} |
There was a problem hiding this comment.
Could we make a coderd.API struct that contains this? Similar to how the AGPL coderd package is structured.
There was a problem hiding this comment.
the public keys are baked in at the package level this way. Isn't this what we want?
It might make it easier to do integration testing if we could inject the keys in as coderd.Options on creation of the API, so that tests could generate their own keys and then use them, but I worry that sort of machinery would be tempting for end users looking to bypass our licensing. Granted, right now they can just modify the keys/2022-08-12 file, but each layer we bubble this up through makes it that much more obvious how to get away with it.
| @@ -0,0 +1,153 @@ | |||
| package coderd | |||
There was a problem hiding this comment.
It seems like this test doesn't have to be internal.
There was a problem hiding this comment.
it modifies the keys variable in-place during the tests (patch paradigm). I want to keep that variable unexported, so the tests need to be internal.
Signed-off-by: Spike Curtis <spike@coder.com>
Signed-off-by: Spike Curtis <spike@coder.com>
PR 1 of 2 for #3279
(next PR will add the
coder license addCLI command that hits this endpoint