automatic import of python-authoritahopeneuler20.03

1 files changed, 268 insertions, 0 deletions

diff --git a/python-authoritah.spec b/python-authoritah.spec
new file mode 100644
index 0000000..b9667b2
--- /dev/null
+++ b/python-authoritah.spec
@@ -0,0 +1,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.
+[![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