Currently this would validate that a KeyId was in the returned wrapper
but then return the base wrapper; and if it required a database lookup
it wouldn't validate it anyways.
All uses of this were for decryption so it didn't actually affect
anything to this point (you'd error later instead of sooner) but for any
case where we need to encrypt against a specific version or derive a key
against a specific version this would be broken, in a way that could
lead you to use the wrong key version.
This also properly sends the Key ID around sessions. This worked
currently for the same reason as above but would have broken for any
session in flight once a key was rotated.
* Add -filter to CLI listing.
This doesn't include docs/Changelog yet, that will come shortly.
* Add changelog
* Add website docs and fix a curl output bug
* Inclusion of the error description
Is your feature request related to a problem? Please describe.
During a failure in creating the target, the exception caused did not come with a description capable of bringing a quick understanding of the problem, just the stacktrace.
Describe the solution you'd like
Use the existing module to include messages.
* Sessions support for read:self and cancel:self permissions. This is automatic with fallback; no API change is needed.
* Strips out values from listing if only self actions are allowed on the resource and the user ID is different. This prevents a default ACL of id=*;type=session;actions=read:self,cancel:self from causing all values to be visible when listing.
* Adds an unprivileged user to development/testing instances. This user has only default permissions plus the ability to authorize sessions in the default target.
* Remove list:self from main
As per futher discussions, we won't be supporting this, in favor of
simply read:self and cancel:self (since listing now already filters out
items on which you have no permissions).
This doesn't remove list:self entirely from the code base as much of
that will simply be converted to read:self and cancel:self -- that will
be in a later PR. However, with this removed if we want to release we
won't expose an API publicly that isn't going to stick around.
When running single-server mode, use public_cluster_addr if given
Right now you don't need to specify a controller address and we use the
cluster listener address; this allows overriding it to the
public_cluster_addr if one is given.
If `controllers` is specified we allow it to be either the cluster
listener or the public cluster address if one is specified before trying
to parse and use it.
Jeff Mitchell
Eth3rn4lBl4ck
Todd Knight
Lars Lehtonen
Jim
Dane Harrigan
s-christoff
Louis Ruch
Randall Morey