%global _empty_manifest_terminate_build 0 Name: python-django-rest-knox Version: 4.2.0 Release: 1 Summary: Authentication for django rest framework License: MIT URL: https://github.com/James1345/django-rest-knox Source0: https://mirrors.nju.edu.cn/pypi/web/packages/58/29/c6eb00493cc4d36443f66b91d67af65b173230d8250088dd5cc08c65b163/django-rest-knox-4.2.0.tar.gz BuildArch: noarch Requires: python3-cryptography Requires: python3-django Requires: python3-djangorestframework %description [![image](https://github.com/James1345/django-rest-knox/workflows/Test/badge.svg?branch=develop)](https://github.com/James1345/django-rest-knox/actions) Authentication Module for django rest auth Knox provides easy to use authentication for [Django REST Framework](https://www.django-rest-framework.org/) The aim is to allow for common patterns in applications that are REST based, with little extra effort; and to ensure that connections remain secure. Knox authentication is token based, similar to the `TokenAuthentication` built in to DRF. However, it overcomes some problems present in the default implementation: - DRF tokens are limited to one per user. This does not facilitate securely signing in from multiple devices, as the token is shared. It also requires *all* devices to be logged out if a server-side logout is required (i.e. the token is deleted). Knox provides one token per call to the login view - allowing each client to have its own token which is deleted on the server side when the client logs out. Knox also provides an option for a logged in client to remove *all* tokens that the server has - forcing all clients to re-authenticate. - DRF tokens are stored unencrypted in the database. This would allow an attacker unrestricted access to an account with a token if the database were compromised. Knox tokens are only stored in a secure hash form (like a password). Even if the database were somehow stolen, an attacker would not be able to log in with the stolen credentials. - DRF tokens track their creation time, but have no inbuilt mechanism for tokens expiring. Knox tokens can have an expiry configured in the app settings (default is 10 hours.) More information can be found in the [Documentation](https://james1345.github.io/django-rest-knox/) # Run the tests locally If you need to debug a test locally and if you have [docker](https://www.docker.com/) installed: simply run the ``./docker-run-tests.sh`` script and it will run the test suite in every Python / Django versions. You could also simply run regular ``tox`` in the root folder as well, but that would make testing the matrix of Python / Django versions a bit more tricky. # Work on the documentation Our documentation is generated by [Mkdocs](https://www.mkdocs.org). You can refer to their documentation on how to install it locally. Another option is to use `mkdocs.sh` in this repository. It will run mkdocs in a [docker](https://www.docker.com/) container. Running the script without any params triggers the `serve` command. The server is exposed on localhost on port 8000. To configure the port the `serve` command will be exposing the server to, you can use the following env var: ``` MKDOCS_DEV_PORT="8080" ``` You can also pass any `mkdocs` command like this: ``` ./mkdocs build ./mkdocs --help ``` Check the [Mkdocs documentation](https://www.mkdocs.org/) for more. %package -n python3-django-rest-knox Summary: Authentication for django rest framework Provides: python-django-rest-knox BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-django-rest-knox [![image](https://github.com/James1345/django-rest-knox/workflows/Test/badge.svg?branch=develop)](https://github.com/James1345/django-rest-knox/actions) Authentication Module for django rest auth Knox provides easy to use authentication for [Django REST Framework](https://www.django-rest-framework.org/) The aim is to allow for common patterns in applications that are REST based, with little extra effort; and to ensure that connections remain secure. Knox authentication is token based, similar to the `TokenAuthentication` built in to DRF. However, it overcomes some problems present in the default implementation: - DRF tokens are limited to one per user. This does not facilitate securely signing in from multiple devices, as the token is shared. It also requires *all* devices to be logged out if a server-side logout is required (i.e. the token is deleted). Knox provides one token per call to the login view - allowing each client to have its own token which is deleted on the server side when the client logs out. Knox also provides an option for a logged in client to remove *all* tokens that the server has - forcing all clients to re-authenticate. - DRF tokens are stored unencrypted in the database. This would allow an attacker unrestricted access to an account with a token if the database were compromised. Knox tokens are only stored in a secure hash form (like a password). Even if the database were somehow stolen, an attacker would not be able to log in with the stolen credentials. - DRF tokens track their creation time, but have no inbuilt mechanism for tokens expiring. Knox tokens can have an expiry configured in the app settings (default is 10 hours.) More information can be found in the [Documentation](https://james1345.github.io/django-rest-knox/) # Run the tests locally If you need to debug a test locally and if you have [docker](https://www.docker.com/) installed: simply run the ``./docker-run-tests.sh`` script and it will run the test suite in every Python / Django versions. You could also simply run regular ``tox`` in the root folder as well, but that would make testing the matrix of Python / Django versions a bit more tricky. # Work on the documentation Our documentation is generated by [Mkdocs](https://www.mkdocs.org). You can refer to their documentation on how to install it locally. Another option is to use `mkdocs.sh` in this repository. It will run mkdocs in a [docker](https://www.docker.com/) container. Running the script without any params triggers the `serve` command. The server is exposed on localhost on port 8000. To configure the port the `serve` command will be exposing the server to, you can use the following env var: ``` MKDOCS_DEV_PORT="8080" ``` You can also pass any `mkdocs` command like this: ``` ./mkdocs build ./mkdocs --help ``` Check the [Mkdocs documentation](https://www.mkdocs.org/) for more. %package help Summary: Development documents and examples for django-rest-knox Provides: python3-django-rest-knox-doc %description help [![image](https://github.com/James1345/django-rest-knox/workflows/Test/badge.svg?branch=develop)](https://github.com/James1345/django-rest-knox/actions) Authentication Module for django rest auth Knox provides easy to use authentication for [Django REST Framework](https://www.django-rest-framework.org/) The aim is to allow for common patterns in applications that are REST based, with little extra effort; and to ensure that connections remain secure. Knox authentication is token based, similar to the `TokenAuthentication` built in to DRF. However, it overcomes some problems present in the default implementation: - DRF tokens are limited to one per user. This does not facilitate securely signing in from multiple devices, as the token is shared. It also requires *all* devices to be logged out if a server-side logout is required (i.e. the token is deleted). Knox provides one token per call to the login view - allowing each client to have its own token which is deleted on the server side when the client logs out. Knox also provides an option for a logged in client to remove *all* tokens that the server has - forcing all clients to re-authenticate. - DRF tokens are stored unencrypted in the database. This would allow an attacker unrestricted access to an account with a token if the database were compromised. Knox tokens are only stored in a secure hash form (like a password). Even if the database were somehow stolen, an attacker would not be able to log in with the stolen credentials. - DRF tokens track their creation time, but have no inbuilt mechanism for tokens expiring. Knox tokens can have an expiry configured in the app settings (default is 10 hours.) More information can be found in the [Documentation](https://james1345.github.io/django-rest-knox/) # Run the tests locally If you need to debug a test locally and if you have [docker](https://www.docker.com/) installed: simply run the ``./docker-run-tests.sh`` script and it will run the test suite in every Python / Django versions. You could also simply run regular ``tox`` in the root folder as well, but that would make testing the matrix of Python / Django versions a bit more tricky. # Work on the documentation Our documentation is generated by [Mkdocs](https://www.mkdocs.org). You can refer to their documentation on how to install it locally. Another option is to use `mkdocs.sh` in this repository. It will run mkdocs in a [docker](https://www.docker.com/) container. Running the script without any params triggers the `serve` command. The server is exposed on localhost on port 8000. To configure the port the `serve` command will be exposing the server to, you can use the following env var: ``` MKDOCS_DEV_PORT="8080" ``` You can also pass any `mkdocs` command like this: ``` ./mkdocs build ./mkdocs --help ``` Check the [Mkdocs documentation](https://www.mkdocs.org/) for more. %prep %autosetup -n django-rest-knox-4.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-django-rest-knox -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Sun Apr 23 2023 Python_Bot - 4.2.0-1 - Package Spec generated