* 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.
* Update deps
This also updates for the new (and required) paradigm for registering
service implementations as spelled out in
https://github.com/grpc/grpc-go/issues/3385
* Roll back dockertest
* Scopes inline version into update request body.
* Users inline version into update request body.
* Group inline version into update and add|set|remove member request body.
* Role inline version into update and add|set|remove grant|principal request body.
* Auth method inline version into update request body.
* Auth Account inline version into update request body.
* host catalog version is inlined for update.
* Gen after merge.
* Submitting template changes for version handling.
* Change auth validity feedback
Move from a bool indicating validity to lack of an error. This allows
the error to be directly returned and typed.
* Fix erroneous line
Don't rely on token for scopes collection actions
This requires `scope_id` to be passed (via query param) for actions on
the scopes collection; that is, listing or creating. However, it removes
the dependency on using the token for the scope of the command. For
actions on a specific scope, we use the given ID to determine the scope
we should be operating at, doing a lookup if necessary.
Existing tests have been updated. Of particular note, the CORS test was
already operating on the scopes collection so served as a good test to
ensure that from an API level the scope_id parameter was being parsed
and passed through (the tests fail without adding that query parameter
in).
Jeff Mitchell
Todd Knight
Michael GaffneyandJeff Mitchell
Jim