参考链接： Python | 扩展和自定义django-allauth
django-auth
I recently ported an app with Google OAuth2 integration from django-social-auth to python-social-auth. Here are some things I noticed that were not mentioned in the porting docs.
最近，我将集成了Google OAuth2的应用程序从django-social-auth移植到python-social-auth 。 这是我注意到的一些移植文档中未提及的内容。
(Note: In the following text I will refer to django-social-auth and
（注意：在下文中，我将参考django-social-auth和
迁移数据库 (Migrating Database)
Last week I migrated the application to Django 1.7. Now that I also switched from DSA to PSA, I wanted to run the migrations but discovered a problem…
上周，我将应用程序迁移到了Django 1.7。 现在，我也从DSA切换到PSA，我想运行迁移，但是发现了一个问题……
$ ./manage.py migrate default
Operations to perform:
Target specific migration: 0001_initial, from default
Running migrations:
Applying default.0001_initial...Traceback (most recent call last):
(...)
django.db.utils.ProgrammingError: relation "social_auth_association" already exists
(Note that default is the short name of the PSA Django app, because the full path is social.apps.django_app.default.)
（请注意， 默认值是PSA Django应用程序的简称，因为完整路径是social.apps.django_app.default 。）
The problem is that PSA tried to create the initial models, but failed because they already existed back from DSA.
问题是PSA尝试创建初始模型，但失败了，因为它们已经从DSA重新存在了。
The porting docs mention that “the models table names were defined to be compatible with those used on django-social-auth, so data is not needed to be migrated”. Therefore we can safely skip the initial migration by faking it:
移植文档提到“模型表名称被定义为与django-social-auth上使用的名称兼容，因此不需要迁移数据”。 因此，我们可以通过伪造来安全地跳过初始迁移：
$ ./manage.py migrate default 0001 --fake
Operations to perform:
Target specific migration: 0001_initial, from default
Running migrations:
Applying default.0001_initial... FAKED
Now we’re at a valid state and can run all other migrations:
现在我们处于有效状态，可以运行所有其他迁移：
$ ./manage.py migrate
刷新访问令牌 (Refreshing an Access Token)
The old way to refresh an access token was the following line of code:
刷新访问令牌的旧方法是以下代码行：
useruser .. social_authsocial_auth .. getget ()() .. refresh_tokenrefresh_token ()
()
This fails with an exception though:
但是，此操作失败，但有一个例外：
TypeError: refresh_token() takes at least 2 arguments (1 given)
The reason is that the refresh_token method now expects a strategy instance as argument. The Django strategy can be loaded using the following code snippet:
原因是refresh_token方法现在希望将策略实例作为参数。 可以使用以下代码段加载Django策略：
UserSocialAuth.tokens (UserSocialAuth.tokens)
In DSA, the tokens property of a UserSocialAuth instance used to return a dictionary of tokens, containing keys like access_token. Now it returns the access token directly. I created an issue in the PSA issue tracker, because I find the naming a bit confusing.
在DSA中， UserSocialAuth实例的tokens属性用于返回令牌字典，其中包含诸如access_token之类的键。 现在，它直接返回访问令牌。 我在PSA问题跟踪器中创建了一个问题 ，因为我发现命名有些混乱。
简化管道扩展 (Simplified Pipeline Extension)
If you want to extend the default pipeline, the old way was to copy-paste the code from the DSA sourcecode and add your custom pipeline entries to it. In PSA, you now have a DEFAULT_AUTH_PIPELINE tuple that can be used in your definition.
如果要扩展默认管道，则旧方法是从DSA源代码中复制粘贴代码，然后向其中添加自定义管道条目。 在PSA中，您现在可以使用DEFAULT_AUTH_PIPELINE元组。
from from social.pipeline social.pipeline import import DEFAULT_AUTH_PIPELINE
DEFAULT_AUTH_PIPELINE
SOCIAL_AUTH_PIPELINE SOCIAL_AUTH_PIPELINE = = DEFAULT_AUTH_PIPELINE DEFAULT_AUTH_PIPELINE (
(
'config.social_auth.fetch_account_access''config.social_auth.fetch_account_access' ,
,
)
)
翻译自: https://www.pybloggers.com/2014/10/migrating-from-django-social-auth-to-python-social-auth/
django-auth
