Jeff Mitchell
feb3aea38f
This allows specifying multiple IDs in grants via an `ids` field, which will eventually become the normal way to specify IDs. Internally, each grant with multiple IDs turns into multiple ACL grants each with a single ID; to make this distinction clearer and allow for better separation of concerns an AclGrant type has been introduced, so really multiple IDs in a Grant turn into multiple AclGrants. The nice thing about doing it this way is that it becomes purely a parsing concern; no actual validation logic has changed. For backwards compatibility with grants already stored in roles, we do not error out if `id` is specified. However, eventually we will simply not support grants with `id` coming via the API; they will fail API validation, such that new grants will require the use of the updated `ids` field. A follow-on PR will plumb this through the service handlers/API/CLI, but I decided to do it in separate chunks to make reviewing easier, given that they are easily separable into the internal and external aspects of the change. * Add CLI/API checks around using ID in grants (#3264) * Plumb through some contexts to remove a lot of deprecated errors (#3268)
13 lines
325 B
Go
13 lines
325 B
Go
// Code generated by "make api"; DO NOT EDIT.
|
|
// Copyright (c) HashiCorp, Inc.
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
|
|
package roles
|
|
|
|
type GrantJson struct {
|
|
Id string `json:"id,omitempty"`
|
|
Ids []string `json:"ids,omitempty"`
|
|
Type string `json:"type,omitempty"`
|
|
Actions []string `json:"actions,omitempty"`
|
|
}
|