7 Commits (ba85a3bc3fb2be769b3eaa4835eac93726c19bd1)

Author	SHA1	Message	Date
Jim	68dd2a66ba	Remove unneeded hclog dependencies as we move forward with events (#1433)	5 years ago
s-christoff	6b78108ecf	Update primary error functions to take a context, deprecate old functions (#1358) ... * 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>	5 years ago
Todd Knight	10e8aeae4b	Subtype Id registration moved to its own package (#1416) ... * Allow repo packages to register subtypes and id prefixes. * Refactor out request authentication logic to a new package as a sibling to handler.	5 years ago
Jeff Mitchell	727d1c7085	Add "no-op" action and use it as default for scope permissions (#1138) ... 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.	5 years ago
Jeff Mitchell	3c430678ae	Fix test scope errors (#1029) ... 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.	5 years ago
Jeff Mitchell	aa570f4e48	Honor child scope list permissions when recursing (#1016) ... 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.	5 years ago
Jeff Mitchell	6cd97a4a6e	Add support for recursive listing (#885)	5 years ago