大概来介绍一下 Django Allauth 改造的期间遇到的一些问题和改造方法,在此之前我只想说——Django Allauth 是屑。
为什么我说 Django Allauth 是屑
入职之初我就接到了一些第三方登录的任务,然而 Django Allauth 将内部封装的太好,暴露的 API 不足,更新又慢,issue 和 PR 很少有人处理,当你需要扩展时,很多情况下你只能用一些 hack 的手段去解决问题,非常蛋疼,所以当时就决定慢慢的切到自己的一套 Auth 体系中。
目前已经做的是第三方登录的部分,账号管理的部分还没有迁移,之前稍微看了一下,要迁移的成本还是比较麻烦的。
迁移成本在哪里
Django 中的账号密码登录一般是由本身提供的 auth 表进行扩展的结果,而 allauth 在此基础上扩充了第三方登录的几个表,再和本身的 auth user 表关联。而这一部分是构建在 Allauth 内部的 model 内,且没有暴露任何的方法来修改结构(当然可能也是因为真的不好改),导致一旦不满足需求就很难搞,因为数据已经放在那里了,刷数据同步的方案对于大流量网站来说也并不是很友好的选择。
此外,在路由上,由于我们需要尽可能的无痛迁移和在渐进式切换时的平稳降级,因此只能通过简单粗暴的路由覆盖操作,这极度依赖路由的解析顺序。
数据库扩展与 provider 变更
说了这么多,其实关键点并不在于「问题在哪里」,而在于「我是怎么解决这些问题的」。
Allauth 一个平台的注册是一个 provider,比如 「wechat」、「weibo」、「qq」,整张表是一对一的关系,那么问题来了,我们知道,国内的平台往往并不是一个 appid 和 key 能搞定的事情,对于 web 和移动端的平台来说,其实是两个 appid 共享一套 unionid,尽管官方提供了一套增加 Provider 的扩展方式,但实际上是没有必要的,因为 Web 和移动端来说,获得用户信息的接口是共享的,而移动端并不用通过后端获取 access_token。在绑定上,实际上也是同一个平台。
因此我们扩充了一张表来解决这个问题,将我们额外的信息放在了额外添加的表中。
之后要解决的就是 admin 的 provider select 问题,它会进行一次校验,所以我们必须要取消这些校验并把 select 改成 input。
首先,我们要取消 Model 层的校验, Proxy 可以对表进行一些覆盖式的操作(但不能改变表结构):
class CustomSocialApp(SocialApp): class Meta: proxy = True def clean_fields(self, exclude=None): # 别校验了 pass def full_clean(self, exclude=None, validate_unique=True): # 别校验了 pass def clean(self, exclude=None, validate_unique=True): # 别校验了 pass
这里我们在原来的 SocialApp 的基础上新建一个属于自己的新的 Admin,他本质上还是操作 SocialApp 表,只是挪出来方便我们自定义而已:
class CustomSocialAppAdmin(SocialAppAdmin): list_display = ('provider_text', 'name') form = CustomAppAdminForm def get_form(self, request, obj=None, **kwargs): kwargs['widgets'] = {'provider': forms.TextInput} return super().get_form(request, obj, **kwargs) def provider_text(self, obj): return obj.provider
但是这样就会遇到一个 provider 的校验问题,这也就是上面我们还没有写完的 CustomAppAdminForm 的部分,我们将校验的部分用自定义的 form 完全取消:
class CustomSocialAppAdminForm(forms.ModelForm): class Meta: model = CustomSocialApp fields = '__all__' widgets = {'provider': forms.TextInput()} def clean(self): # 别校验了 if self.has_error('provider'): del self._errors['provider'] self.cleaned_data['provider'] = self.data['provider'] return self.cleaned_data
这样就完成了校验的修改,成了一个完全体的 input 覆盖了原来的 select。
第三方登录与绑定流程
上面可以任意在表中拓展 provider 了 ,但重头戏其实是:搞清楚 allauth 原本的登录和绑定流程,完美的 copy 一份流程,这样才能实现平稳降级和无痛迁移。
查找账号
登录流程
注册流程
绑定流程
只要按照这个流程实现下来就可以了,而同一平台多 provider(appid)的差异功能与核心部分无关,可以在各社交媒体对应的文件中单独实现。
构建新的账号系统
现在我们彻底将第三方登录抽离了出来,接下来需要抽出账号的部分,账号登录和注册本质上还是 Django 提供的那些东西,因此比较好抽,需要兼容的部分主要在于「忘记密码」和「重置密码」。
我们来思考一下为什么这部分需要做兼容:
一般来说我们都是在重置密码时在手机或者邮箱里收到一个验证邮件,里面会附上一个随机字符串用来保证连接的唯一性。而在我们替换过程中,我们不能让一群用户已经发送过但还没有使用的随机字符串不可用,从可读的角度来看,生成的内容也应该和原来差不多(同时也是避免冲突),因此需要抄一下它的忘记密码。
在 account/forms 中表明了 token 的生成算法:
from django.contrib.auth.tokens import PasswordResetTokenGenerator token_generator = PasswordResetTokenGenerator() # 生成 token key = token_generator.make_token(user) # 检查 token token_generator.check_token(user, key)
Allauth 中将 user 用 base36 加密了,兼容 Python2,所以 utils 中的语句略长,由于我们直接是 Python3,所以只剩下这些句子:
from django.utils.http import base36_to_int from django.utils.http import int_to_base36 def user_pk_to_url_str(user): return int_to_base36(user.pk) def url_str_to_user_pk(s): return base36_to_int(s)
所有内容将会被存储在 account_emailconfirmation 表中,这样就能保证对应的关系了。
总结
在账号的部分由于还没有改完,所以可以说的不多,只是做了一些微小的工作,对于这种可能需要根据国情定制的需求,建议大家还是小心使用。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
以前版本的改造使用RestaAdapter,并提供了启用日志的功能。为什么在改型2.0中删除了该功能? 要启用日志,我必须。。 这是唯一的解决办法吗?以前的规定非常方便...
本文向大家介绍详解weex默认webpack.config.js改造,包括了详解weex默认webpack.config.js改造的使用技巧和注意事项,需要的朋友参考一下 本文介绍了weex默认webpack.config.js改造,分享给大家,具体如下: 解决的问题: 由于weex默认的webpack配置,会导致在src文件夹下的每一个.vue在temp文件夹下生成对应的一个.js文件,该js文
本文向大家介绍详解linux SSH登录流程,包括了详解linux SSH登录流程的使用技巧和注意事项,需要的朋友参考一下 本文给大家详细介绍了ssh 密钥登录远程服务器流程和注意事项,以下是详细内容: 密钥登录比密码登录安全,主要是因为他使用了非对称加密,登录过程中需要用到密钥对。整个登录流程如下: 远程服务器持有公钥,当有用户进行登录,服务器就会随机生成一串字符串,然后发送给正在进行登录的用户
http://172.16.7.203/sfAppServices/SF_UserLogin.svc/rest/login/ 在这个用户名和密码是它的一部分,我需要发布用户从edittext输入的用户名和密码,并得到如下json响应 如何使用改装获得json。我已使用asynctask成功完成此操作。但感觉很难通过改造来实现。我的问题是 哪个是基本网址? 在应该在post方法中公开的接口中。 如何
我试图使用refrofit2、kotlin和loging-拦截器记录所有请求(使用网络拦截器): 改造:“2.0.2” okhttp3 : “3.2.0” com.squareup.okhttp3:logging-interceptor 3.2.0 喜欢: 它只是打印: 到底发生了什么? -编辑- 记录器不会显示在主线程上执行请求的错误,因此请小心。
问题内容: 我是JSON解析的新手,我使用Square的Retrofit库,遇到了这个问题。 我正在尝试解析此JSON响应: 这是我的模型: … 我的界面: 我的成功方法: 当我将其用于成功方法时,会引发错误 预期为BEGIN_OBJECT,但在第1行column2处为BEGIN_ARRAY 怎么了 问题答案: 现在,您正在解析响应,就好像它是这样格式化的: 异常告诉您,您期望在根目录有一个对象,