Well, being extremely thorough; read from file on startup and then use
online commands for modifications is perfectly doable too (and how some
things work) but I feel like that will be hard for people to use.
On Tue, 17 Apr 2018, dormando wrote:
> Right; I'm saying there needs to be a mechanism
Right; I'm saying there needs to be a mechanism of loading what the
current tokens are :) Which are probably going to be from a file on disk.
A rotation would be staged modifications to this file + reload commands or
auto reloading.
Pulling from file would be necessary to avoid losing tokens
Reload would be handy to have but not absolutely necessary.
For rotation, one would just set up their second token (the new one) at
some point in time. Any time after that clients can transition to the new
token. Once all clients are transitioned to the new token, the original
token would then
Hey,
Thanks for the feedback! That should be doable. I'm used to this being a
pain with TLS ticket rotation/etc anyway. This'll probably end up
requiring a reload mechanism but shouldn't be too messy, I guess?
On Mon, 16 Apr 2018, John Reilly wrote:
> Hi dormando,I would love to see this
Hi dormando,
I would love to see this change. One thing that would be great to have is
support for multiple tokens for the purpose of key rotation. If there are
roles, one could just assign 2 equivalent roles with different tokens, but
in the absence of roles as you mentioned just having the
Hey,
In the wake of all this exposed-internet fun, I want to do something I
should've years ago; add support for a basic authentication token.
Currently, with binary protocol, you have the option of using SASL. This
requires compiling against sasl, a client that both speaks binprot and
sasl, and
