plain.oauth 0.7.0__tar.gz → 0.7.2__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (21) hide show
  1. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/PKG-INFO +4 -32
  2. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/README.md +3 -31
  3. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/README.md +3 -31
  4. plain_oauth-0.7.2/plain/oauth/default_settings.py +1 -0
  5. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/pyproject.toml +1 -1
  6. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/LICENSE +0 -0
  7. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/__init__.py +0 -0
  8. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/config.py +0 -0
  9. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/exceptions.py +0 -0
  10. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/migrations/0001_initial.py +0 -0
  11. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/migrations/0002_alter_oauthconnection_options_and_more.py +0 -0
  12. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/migrations/0003_alter_oauthconnection_access_token_and_more.py +0 -0
  13. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/migrations/0004_alter_oauthconnection_access_token_and_more.py +0 -0
  14. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/migrations/0005_alter_oauthconnection_unique_together_and_more.py +0 -0
  15. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/migrations/__init__.py +0 -0
  16. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/models.py +0 -0
  17. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/providers.py +0 -0
  18. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/staff.py +0 -0
  19. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/templates/oauth/error.html +0 -0
  20. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/urls.py +0 -0
  21. {plain_oauth-0.7.0 → plain_oauth-0.7.2}/plain/oauth/views.py +0 -0
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.1
2
2
  Name: plain.oauth
3
- Version: 0.7.0
3
+ Version: 0.7.2
4
4
  Summary: OAuth login and API access for Plain.
5
5
  Home-page: https://plainframework.com
6
6
  License: BSD-3-Clause
@@ -21,6 +21,8 @@ Description-Content-Type: text/markdown
21
21
 
22
22
  <!-- This file is compiled from plain-oauth/plain/oauth/README.md. Do not edit this file directly. -->
23
23
 
24
+ <!-- This file is compiled from plain-oauth/plain/oauth/README.md. Do not edit this file directly. -->
25
+
24
26
  # plain.oauth
25
27
 
26
28
  Let users log in with OAuth providers.
@@ -160,36 +162,6 @@ That's pretty much it!
160
162
 
161
163
  ## Advanced usage
162
164
 
163
- ### Email addresses should be unique
164
-
165
- When you're integrating with an OAuth provider,
166
- we think that the user's email address is the best "primary key" when linking to your `User` model in your app.
167
- Unfortunately in Django, by default an email address is not required to be unique!
168
- **We strongly recommend you require email addresses to be unique in your app.**
169
-
170
- [As suggested by the Django docs](https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project),
171
- one way to do this is to have your own `User` model:
172
-
173
- ```python
174
- # In an app named "users", for example
175
- from plain.auth.models import BaseUser
176
-
177
- class User(BaseUser):
178
- email = models.EmailField(unique=True)
179
-
180
-
181
- # In settings.py
182
- AUTH_USER_MODEL = 'users.User'
183
- ```
184
-
185
- You'll also notice that there are no "email confirmation" or "email verification" flows in this library.
186
- This is also intentional.
187
- You can implement something like that yourself if you need to,
188
- but the easier solution in our opinion is to use an OAuth provider you *trust to have done that already*.
189
- If you look at our [provider examples](https://github.com/forgepackages/plain-oauth/tree/master/provider_examples) you'll notice how we often use provider APIs to get the email address which is "primary" and "verified" already.
190
- If they've already done that work,
191
- then we can just use that information.
192
-
193
165
  ### Handling OAuth errors
194
166
 
195
167
  The most common error you'll run into is if an existing user clicks a login button,
@@ -298,7 +270,7 @@ python manage.py check --database default
298
270
 
299
271
  ## FAQs
300
272
 
301
- ### How is this different from [other Django OAuth libraries](https://djangopackages.org/grids/g/oauth/)?
273
+ ### How is this different from [Django OAuth libraries](https://djangopackages.org/grids/g/oauth/)?
302
274
 
303
275
  The short answer is that *it does less*.
304
276
 
@@ -1,5 +1,7 @@
1
1
  <!-- This file is compiled from plain-oauth/plain/oauth/README.md. Do not edit this file directly. -->
2
2
 
3
+ <!-- This file is compiled from plain-oauth/plain/oauth/README.md. Do not edit this file directly. -->
4
+
3
5
  # plain.oauth
4
6
 
5
7
  Let users log in with OAuth providers.
@@ -139,36 +141,6 @@ That's pretty much it!
139
141
 
140
142
  ## Advanced usage
141
143
 
142
- ### Email addresses should be unique
143
-
144
- When you're integrating with an OAuth provider,
145
- we think that the user's email address is the best "primary key" when linking to your `User` model in your app.
146
- Unfortunately in Django, by default an email address is not required to be unique!
147
- **We strongly recommend you require email addresses to be unique in your app.**
148
-
149
- [As suggested by the Django docs](https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project),
150
- one way to do this is to have your own `User` model:
151
-
152
- ```python
153
- # In an app named "users", for example
154
- from plain.auth.models import BaseUser
155
-
156
- class User(BaseUser):
157
- email = models.EmailField(unique=True)
158
-
159
-
160
- # In settings.py
161
- AUTH_USER_MODEL = 'users.User'
162
- ```
163
-
164
- You'll also notice that there are no "email confirmation" or "email verification" flows in this library.
165
- This is also intentional.
166
- You can implement something like that yourself if you need to,
167
- but the easier solution in our opinion is to use an OAuth provider you *trust to have done that already*.
168
- If you look at our [provider examples](https://github.com/forgepackages/plain-oauth/tree/master/provider_examples) you'll notice how we often use provider APIs to get the email address which is "primary" and "verified" already.
169
- If they've already done that work,
170
- then we can just use that information.
171
-
172
144
  ### Handling OAuth errors
173
145
 
174
146
  The most common error you'll run into is if an existing user clicks a login button,
@@ -277,7 +249,7 @@ python manage.py check --database default
277
249
 
278
250
  ## FAQs
279
251
 
280
- ### How is this different from [other Django OAuth libraries](https://djangopackages.org/grids/g/oauth/)?
252
+ ### How is this different from [Django OAuth libraries](https://djangopackages.org/grids/g/oauth/)?
281
253
 
282
254
  The short answer is that *it does less*.
283
255
 
@@ -1,3 +1,5 @@
1
+ <!-- This file is compiled from plain-oauth/plain/oauth/README.md. Do not edit this file directly. -->
2
+
1
3
  # plain.oauth
2
4
 
3
5
  Let users log in with OAuth providers.
@@ -137,36 +139,6 @@ That's pretty much it!
137
139
 
138
140
  ## Advanced usage
139
141
 
140
- ### Email addresses should be unique
141
-
142
- When you're integrating with an OAuth provider,
143
- we think that the user's email address is the best "primary key" when linking to your `User` model in your app.
144
- Unfortunately in Django, by default an email address is not required to be unique!
145
- **We strongly recommend you require email addresses to be unique in your app.**
146
-
147
- [As suggested by the Django docs](https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project),
148
- one way to do this is to have your own `User` model:
149
-
150
- ```python
151
- # In an app named "users", for example
152
- from plain.auth.models import BaseUser
153
-
154
- class User(BaseUser):
155
- email = models.EmailField(unique=True)
156
-
157
-
158
- # In settings.py
159
- AUTH_USER_MODEL = 'users.User'
160
- ```
161
-
162
- You'll also notice that there are no "email confirmation" or "email verification" flows in this library.
163
- This is also intentional.
164
- You can implement something like that yourself if you need to,
165
- but the easier solution in our opinion is to use an OAuth provider you *trust to have done that already*.
166
- If you look at our [provider examples](https://github.com/forgepackages/plain-oauth/tree/master/provider_examples) you'll notice how we often use provider APIs to get the email address which is "primary" and "verified" already.
167
- If they've already done that work,
168
- then we can just use that information.
169
-
170
142
  ### Handling OAuth errors
171
143
 
172
144
  The most common error you'll run into is if an existing user clicks a login button,
@@ -275,7 +247,7 @@ python manage.py check --database default
275
247
 
276
248
  ## FAQs
277
249
 
278
- ### How is this different from [other Django OAuth libraries](https://djangopackages.org/grids/g/oauth/)?
250
+ ### How is this different from [Django OAuth libraries](https://djangopackages.org/grids/g/oauth/)?
279
251
 
280
252
  The short answer is that *it does less*.
281
253
 
@@ -0,0 +1 @@
1
+ OAUTH_LOGIN_PROVIDERS: dict
@@ -1,6 +1,6 @@
1
1
  [tool.poetry]
2
2
  name = "plain.oauth"
3
- version = "0.7.0"
3
+ version = "0.7.2"
4
4
  description = "OAuth login and API access for Plain."
5
5
  authors = ["Dave Gaeddert <dave.gaeddert@dropseed.dev>"]
6
6
  license = "BSD-3-Clause"
File without changes