* Start of test
* Add a test for existing GrantsForUser functionality.
The test has randomization built in to allocate users across groups and
both users and groups across roles. It tracks which users and groups
have been assigned to which roles, then ensures that GrantsForUser
returns the correct set of roles for a given user.
This required modifying the CTE in GrantsForUser to return role_id as
well.
This doesn't test managed groups yet, that will come in a follow-on PR.
* Migrate the server upsert query to use database time
This ensures that we are using consistent ideas of time regardless of
the local time on each worker (for this query).
* Fix insert part of the upsert query
This PR changes delete behavior:
* On success, a 204 is returned rather than a 200 with an empty JSON object
* The CLI now passes through the 404 error if encountered instead of swallowing it
It also updates formatting for JSON to use the response body, which means that the item (or items) in the JSON format are actually the format across the wire, instead of being reinterpreted by unmarshaling into the Go SDK and then remarshaling.
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.
This keeps only essential information in list output for auth methods
when the user is u_anon. Boundary's default is to allow listing of
auth methods for anonymous users to allow discovery of authentication
points, but there's no need to return more information about internal
configuration than necessary.
I'm not sure why it was doing it the other way with assuming the string
being built would always have a space at the end, but, this way is
easier to understand and fixes a bug where there wasn't a space being
left between some fields.
BK clued me into the fact that for some types, similar alignment
problems exist as with the normal atomic package (e.g. 64-bit types on
32-bit architectures) if they are not pointer values. So change the few
places they weren't pointers to pointers.
None of these are 64-bit, but it feels like best practice for using the
library and should just standardize on it.
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
