summaryrefslogtreecommitdiff
path: root/python-django-rest-knox.spec
blob: bb51dd5f16db5843a22d233fe6d4918da6949eed (plain)
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
%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 <Python_Bot@openeuler.org> - 4.2.0-1
- Package Spec generated