@@ -91,7 +91,7 @@ as the information returned by the IdentityProvider is given to the Authorizer w
91
91
92
92
Authentication always takes precedence because if no user is authenticated,
93
93
no authorization checks need to be made,
94
- as all requests requiring _authorization_ must first complete _authentication_ .
94
+ as all requests requiring * authorization * must first complete * authentication * .
95
95
96
96
Identity Providers
97
97
******************
@@ -118,11 +118,11 @@ This User object will be available as `self.current_user` in any request handler
118
118
Request methods decorated with tornado's `@web.authenticated ` decorator
119
119
will only be allowed if this method returns something.
120
120
121
- The User object will be a Python :py:class: `dataclasses.dataclass `, `jupyter_server.auth.User `:
121
+ The User object will be a Python :py:class: `dataclasses.dataclass ` - `jupyter_server.auth.User `:
122
122
123
123
.. autoclass :: jupyter_server.auth.User
124
124
125
- A custom IdentityProvider _may_ return a custom subclass.
125
+ A custom IdentityProvider * may * return a custom subclass.
126
126
127
127
128
128
The next method an identity provider has is :meth: `~jupyter_server.auth.IdentityProvider.identity_model `.
@@ -183,7 +183,7 @@ Authorization
183
183
*************
184
184
185
185
Authorization is the second step in allowing an action,
186
- after a user has been _authenticated_ by the IdentityProvider.
186
+ after a user has been * authenticated * by the IdentityProvider.
187
187
188
188
Authorization in Jupyter Server serves to provide finer grained control of access to its
189
189
API resources. With authentication, requests are accepted if the current user is known by
0 commit comments