%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.
[![Build Status](https://travis-ci.org/shoppimon/authoritah.svg?branch=master)](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.
[![Build Status](https://travis-ci.org/shoppimon/authoritah.svg?branch=master)](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.
[![Build Status](https://travis-ci.org/shoppimon/authoritah.svg?branch=master)](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