In preparation for Pavex's open beta, we must move away from the rudimental activation checks implemented in #173. This PR is a first step in that direction.
We still use a "fixed" activation key (the same for all beta testers), but we move validation to a remote server, api.pavex.dev.
The activation key entered by the user is forwarded to the server to:
Check its validity
Obtain a short-lived (2 days) CLI token
The CLI token is cached on disk, allowing Pavex to be used offline for up to 2 days.
The cached token is refreshed in the background if it's older than 10 minutes to maximise the offline usage window. We could be more aggressive with the refreshing logic, but I don't want to overwhelm the server with unnecessary requests.
Misc:
move away from secrecy in favour of redact
fix telemetry setup to emit an event when a span closes rather than exits
In preparation for Pavex's open beta, we must move away from the rudimental activation checks implemented in #173. This PR is a first step in that direction. We still use a "fixed" activation key (the same for all beta testers), but we move validation to a remote server, api.pavex.dev. The activation key entered by the user is forwarded to the server to:
The CLI token is cached on disk, allowing Pavex to be used offline for up to 2 days.
The cached token is refreshed in the background if it's older than 10 minutes to maximise the offline usage window. We could be more aggressive with the refreshing logic, but I don't want to overwhelm the server with unnecessary requests.
Misc:
secrecy
in favour ofredact