1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
|
%global _empty_manifest_terminate_build 0
Name: python-authoritah
Version: 0.2.0
Release: 1
Summary: Lightweight, framework agnostic, context based RBAC authorization library
License: Apache 2.0
URL: https://github.com/shoppimon/authoritah
Source0: https://mirrors.nju.edu.cn/pypi/web/packages/20/d9/605b961bedf0dc446d80083d63aed78a5d4af402465e17f07dcb76f2a875/authoritah-0.2.0.tar.gz
BuildArch: noarch
Requires: python3-six
%description
Authoritah is a Python RBAC library. It is designed to be framework
agnostic, in the sense that it is not coupled with any Web framework or ORM
library. In addition, Authoritah provides a highly granular role system using
a unique approach of context-based role resolution.
[](https://travis-ci.org/shoppimon/authoritah)
## Compatibility
We test Authoritah on Python 3.5, 3.6, 3.7 and Pypy 3. It is possible that
older versions of Authoritah will work with Python 2.7 as well, but Python
versions below 3.5 are not supported.
## Installation
The easiest way to install Authoritah is via pip:
pip install authoritah
## Overview & Terminology
The following terms are common in many authorization frameworks, but can have
specific meaning in *authoritah* so it is important to clarify them first:
### Identities
In simple terms, an identity is a user - an entity using the system (be it a
person, a machine authenticating with an API key, a default "anonymous" user,
etc.) Identities can have **roles** - in *authoritah*, an identity's roles are
usually in relation to a given **context object**, although identities can have
default roles as well.
In *authoritah* you are not expected to use a specific structure for identity
objects - they are opaque as far as the library is concerned, and are only
passed around between different callables you provide.
### Roles
A role is given to an identity, and defines a set of **permissions** - actions
that the user is allowed to perform on an object or in the system.
An identity can have more than one role (for example a user may be both a
**hiring_manager** and a **content_editor**). In addition, roles can inherit
permissions from one or more other roles (for example, a **content_editor** can
inherit from **content_viewer**).
Unlike many other authorization frameworks, in *authoritah* roles are not
global (although they can be), but are derived from context - for example a
user may be a **content_editor** for all articles, or may be a
**content_editor** only for the articles they created, and **content_viewer**
for all other articles.
### Permissions
Permissions, simply put, are "rights granted to a given identity based on its
roles". For example, someone with a **content_editor** role have the
**article_edit**, **article_publish** and **article_unpublish** permissions.
Implementing authorization checks in a system normally involves checking
whether the user has one or more permissions granted to them before proceeding
with an action.
### Strict Mode:
The Authorizer class may be instantiated with strict=True (defaults to False).
Strict mode can raise exceptions in two cases:
* If is_allowed is called for a permission not defined in any of the roles defined.
* If a role in the identity provided to is_allowed is not defined
This is useful to check if one forgot to add a role or permission.
### Context Objects
The **context object** is the object on which the operation is performed. For
example, when editing an article the context object is the article. As
mentioned, in *authoritah* context objects have a more central role than
with many other authorization frameworks - they are taken into account when
deciding the user's role.
## Quick Start
The following is a quick start guide to applying authorization to your code
using *authoritah*.
We'll follow an example of an imaginary, simplified content management system
with 3 objects: articles, comments and users.
### 1. Define Roles and Permissions
As with any RBAC system, it is recommended to start with defining some roles
and what permissions they grant. With *Authoritah*, it is recommended to think
of roles in relation to objects in the system.
You can define your roles and permissions in a configuration file - a `YAML` or
`JSON`, or even a Python `dict`:
%package -n python3-authoritah
Summary: Lightweight, framework agnostic, context based RBAC authorization library
Provides: python-authoritah
BuildRequires: python3-devel
BuildRequires: python3-setuptools
BuildRequires: python3-pip
%description -n python3-authoritah
Authoritah is a Python RBAC library. It is designed to be framework
agnostic, in the sense that it is not coupled with any Web framework or ORM
library. In addition, Authoritah provides a highly granular role system using
a unique approach of context-based role resolution.
[](https://travis-ci.org/shoppimon/authoritah)
## Compatibility
We test Authoritah on Python 3.5, 3.6, 3.7 and Pypy 3. It is possible that
older versions of Authoritah will work with Python 2.7 as well, but Python
versions below 3.5 are not supported.
## Installation
The easiest way to install Authoritah is via pip:
pip install authoritah
## Overview & Terminology
The following terms are common in many authorization frameworks, but can have
specific meaning in *authoritah* so it is important to clarify them first:
### Identities
In simple terms, an identity is a user - an entity using the system (be it a
person, a machine authenticating with an API key, a default "anonymous" user,
etc.) Identities can have **roles** - in *authoritah*, an identity's roles are
usually in relation to a given **context object**, although identities can have
default roles as well.
In *authoritah* you are not expected to use a specific structure for identity
objects - they are opaque as far as the library is concerned, and are only
passed around between different callables you provide.
### Roles
A role is given to an identity, and defines a set of **permissions** - actions
that the user is allowed to perform on an object or in the system.
An identity can have more than one role (for example a user may be both a
**hiring_manager** and a **content_editor**). In addition, roles can inherit
permissions from one or more other roles (for example, a **content_editor** can
inherit from **content_viewer**).
Unlike many other authorization frameworks, in *authoritah* roles are not
global (although they can be), but are derived from context - for example a
user may be a **content_editor** for all articles, or may be a
**content_editor** only for the articles they created, and **content_viewer**
for all other articles.
### Permissions
Permissions, simply put, are "rights granted to a given identity based on its
roles". For example, someone with a **content_editor** role have the
**article_edit**, **article_publish** and **article_unpublish** permissions.
Implementing authorization checks in a system normally involves checking
whether the user has one or more permissions granted to them before proceeding
with an action.
### Strict Mode:
The Authorizer class may be instantiated with strict=True (defaults to False).
Strict mode can raise exceptions in two cases:
* If is_allowed is called for a permission not defined in any of the roles defined.
* If a role in the identity provided to is_allowed is not defined
This is useful to check if one forgot to add a role or permission.
### Context Objects
The **context object** is the object on which the operation is performed. For
example, when editing an article the context object is the article. As
mentioned, in *authoritah* context objects have a more central role than
with many other authorization frameworks - they are taken into account when
deciding the user's role.
## Quick Start
The following is a quick start guide to applying authorization to your code
using *authoritah*.
We'll follow an example of an imaginary, simplified content management system
with 3 objects: articles, comments and users.
### 1. Define Roles and Permissions
As with any RBAC system, it is recommended to start with defining some roles
and what permissions they grant. With *Authoritah*, it is recommended to think
of roles in relation to objects in the system.
You can define your roles and permissions in a configuration file - a `YAML` or
`JSON`, or even a Python `dict`:
%package help
Summary: Development documents and examples for authoritah
Provides: python3-authoritah-doc
%description help
Authoritah is a Python RBAC library. It is designed to be framework
agnostic, in the sense that it is not coupled with any Web framework or ORM
library. In addition, Authoritah provides a highly granular role system using
a unique approach of context-based role resolution.
[](https://travis-ci.org/shoppimon/authoritah)
## Compatibility
We test Authoritah on Python 3.5, 3.6, 3.7 and Pypy 3. It is possible that
older versions of Authoritah will work with Python 2.7 as well, but Python
versions below 3.5 are not supported.
## Installation
The easiest way to install Authoritah is via pip:
pip install authoritah
## Overview & Terminology
The following terms are common in many authorization frameworks, but can have
specific meaning in *authoritah* so it is important to clarify them first:
### Identities
In simple terms, an identity is a user - an entity using the system (be it a
person, a machine authenticating with an API key, a default "anonymous" user,
etc.) Identities can have **roles** - in *authoritah*, an identity's roles are
usually in relation to a given **context object**, although identities can have
default roles as well.
In *authoritah* you are not expected to use a specific structure for identity
objects - they are opaque as far as the library is concerned, and are only
passed around between different callables you provide.
### Roles
A role is given to an identity, and defines a set of **permissions** - actions
that the user is allowed to perform on an object or in the system.
An identity can have more than one role (for example a user may be both a
**hiring_manager** and a **content_editor**). In addition, roles can inherit
permissions from one or more other roles (for example, a **content_editor** can
inherit from **content_viewer**).
Unlike many other authorization frameworks, in *authoritah* roles are not
global (although they can be), but are derived from context - for example a
user may be a **content_editor** for all articles, or may be a
**content_editor** only for the articles they created, and **content_viewer**
for all other articles.
### Permissions
Permissions, simply put, are "rights granted to a given identity based on its
roles". For example, someone with a **content_editor** role have the
**article_edit**, **article_publish** and **article_unpublish** permissions.
Implementing authorization checks in a system normally involves checking
whether the user has one or more permissions granted to them before proceeding
with an action.
### Strict Mode:
The Authorizer class may be instantiated with strict=True (defaults to False).
Strict mode can raise exceptions in two cases:
* If is_allowed is called for a permission not defined in any of the roles defined.
* If a role in the identity provided to is_allowed is not defined
This is useful to check if one forgot to add a role or permission.
### Context Objects
The **context object** is the object on which the operation is performed. For
example, when editing an article the context object is the article. As
mentioned, in *authoritah* context objects have a more central role than
with many other authorization frameworks - they are taken into account when
deciding the user's role.
## Quick Start
The following is a quick start guide to applying authorization to your code
using *authoritah*.
We'll follow an example of an imaginary, simplified content management system
with 3 objects: articles, comments and users.
### 1. Define Roles and Permissions
As with any RBAC system, it is recommended to start with defining some roles
and what permissions they grant. With *Authoritah*, it is recommended to think
of roles in relation to objects in the system.
You can define your roles and permissions in a configuration file - a `YAML` or
`JSON`, or even a Python `dict`:
%prep
%autosetup -n authoritah-0.2.0
%build
%py3_build
%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .
%files -n python3-authoritah -f filelist.lst
%dir %{python3_sitelib}/*
%files help -f doclist.lst
%{_docdir}/*
%changelog
* Fri May 05 2023 Python_Bot <Python_Bot@openeuler.org> - 0.2.0-1
- Package Spec generated
|
