* Reorder session authz checks
This implements a mechanism for service handlers to pass a repo
satisfying an interface into the scope IDs listing function. The purpose
of this interface is to allow the same function to perform authorization
checking against resources rather than requiring service handlers to
fetch all resources in the determined set of scopes and then perform
this checking. While this could be done in each service handler, this
approach centralizes the logic, which has the nice benefit of removing
some boilerplate from service handler list functions that have adapted
to it.
Tests haven't changed, which is expected -- the function should return
exactly what was being returned before, simply faster.
* refactor (controller): Use a grpc server for the grpc-gateway
This starts a grpc server for the grpc-gateway. The new gateway
server uses an in-memory listener which also supports "dialing", so
the http proxy can connect to the in-memory listener.
This change allows us to use all grpc server features and was in part
motivated by a need for an interceptor of inbound requests. With that
said, having a "proper" grpc server for the gateway will provide a lot
more flexibility and capabilities moving forward.
The request context will still be verified via middleware in the
http proxy (see wrapHandlerWithCommonFuncs). This verified context
will be serialized into a protobuf and sent along to the grpc-gateway
via metadata where an interceptor will add the verified request
info to the request's context (see requestCtxInterceptor). The
interceptor will verify the serialized request info via a shared ticket
with it's companion in-memory http proxy. FYI: the ticket is simply
random base62 string (see db.NewPrivateId).
This change also necessitated a minor change to services. We need to
return an empty response instead of nil, nil when there are no errors
and the response is empty.
* refactor (handlers): Rename gRPC Gateway filter
Originally, this was called an OutgoingInterceptor, which is an
unfortunate name since it's not an interceptor. Now that we're
refactoring the gateway stuff and have proper interceptors, renaming
this should remove ambiguity
* refactor: Rework how 204 with empty msg is handled
Recent changes to grpc gateway has necessitated a change to how
204s are handled by the gateway
* tests (bats): Check status codes for delete operations
This moves the generated pb files to the `sdk` module. This allows third parties to make use of them if desired (e.g. in upcoming plugins) and moves away from the `gen` nomenclature in the directory, since we are going to be adding some extra interface functions to the messages.
* add new error funcs which take a ctx and deprecate existing funcs
* use context where available when writing error events
* remove circular internal/errors pkg dep
* suppress some chatty errors using errors.WithoutEvent()
* convert auth oidc funcs to take context where needed to write events
Co-authored-by: Jim <jlambert@hashicorp.com>
Because of listing visibility, if no actions are assigned to a user for
an individual resource, it's excluded from the list. This is fine and
good. However, when we made a change in 0.2.0 to restrict the
information returned from listing for the anonymous user for scopes and
auth methods, it exposed the fact that because of the way this
visibility works we had to add `read` to scopes by default -- thereby
rather defeating the purpose of restricting what goes back to `u_anon`
requests.
The purpose of "no-op" is to never be used for real actions within the
API, but as something that can be granted to specifically enable
visibility for the targeted user. This makes the controls over list
visibility much more granular.
When using a disabled verifier context we were faking scope information. Due to other recent changes, this was now causing test errors. This adjusts that flow to actually query the DB, fixing tests and making them more like real code.
Current behavior is that you need list grant on the parent scope when
recursively listing, and this is sufficient. This is good for
administrative workflows but can be unintuitive for resources that only
exist at a project level. This change allows permissions on the child
scope to also be taken into account, so that you can start a recursive
list from a parent scope without direct list support on that scope but
still get back child scopes for which list access is granted.
This also fixes a bug where visibility of a scope for recursive listing
would be based on whether the user had list resources for roles within
that scope instead of for the resource type in question.
Jeff Mitchell
Jim
s-christoffandJim
Todd Knight