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.
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.
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.
* 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.
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
Lars Lehtonen
Jim