openstack
/
oslo.policy
Code Issues Proposed changes

Add minor nits in testing documentation 

This commit addresses nits from
https://review.openstack.org/#/c/604192/1

Change-Id: I2ca0cd67eca4d1b2d0320f7ecb40c9ff55229b12
This commit is contained in:
Lance Bragstad 2018-10-16 17:38:29 +00:00
parent 25b4e3daba
commit f682dab9a9
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/source/user/usage.rst
View File

@ -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:
::