From f682dab9a9b558200f84d062db46da281345d4cc Mon Sep 17 00:00:00 2001 From: Lance Bragstad Date: Tue, 16 Oct 2018 17:38:29 +0000 Subject: Add minor nits in testing documentation This commit addresses nits from https://review.openstack.org/#/c/604192/1 Change-Id: I2ca0cd67eca4d1b2d0320f7ecb40c9ff55229b12 --- doc/source/user/usage.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/source/user/usage.rst b/doc/source/user/usage.rst index 454a58a..0e1554b 100644 --- a/doc/source/user/usage.rst +++ b/doc/source/user/usage.rst @@ -466,7 +466,7 @@ required a policy file, since the default policies were in the service itself. At this point, it is important to note that policy enforcement requires an authorization context based on the user making the request (e.g., is the user allowed to do the operation they're asking to do). Within OpenStack, this -authorization context it relayed to services by the token used to call an API, +authorization context is relayed to services by the token used to call an API, which comes from an OpenStack identity service. In its purest form, you can think of authorization context as the roles a user has on a project, domain, or system. Services can feed the authorization context into policy enforcement, @@ -500,7 +500,7 @@ functionality of their service without needing to understand the intricacies of policy enforcement. Unfortunately, bypassing API authorization testing comes at the expense of introducing gaps where the default policies may break unexpectedly with new changes. If the tests don't assert the default behavior, -it's likely that seemly simple changes negatively impact users or operators, +it's likely that seemingly simple changes negatively impact users or operators, regardless of that being the intent of the developer. Testing policies @@ -532,8 +532,8 @@ default policy like the following: policy.RuleDefault('identity:create_region', 'role:admin') ) -Enforcement here is straightforward in that a user with a role called admin may -access this API. You can model this in a request context by setting these +Enforcement here is straightforward in that a user with a role called ``admin`` +may access this API. You can model this in a request context by setting these attributes explicitly: :: -- cgit v1.2.1