现在开始进入真正功能的开发和实现
1. 用户注册
显然这个页面目前需要分析各种校验和验证以及正常的提示和报错信息。
如鼠标失焦后,提示用户名已注册;
密码不对,密码不符合规则; 密码加密
图形验证码不正确等;(防止机器自动恶意注册)
获取短信验证码后,1分钟的有效等等。(手机号的有效性以及防止人家恶意花光你的短信推送)
所以,第一步是 form表单验证+接收+再验证----->数据保存到数据库。
那么保存到数据库,站在python和Django后端的角度来看,肯定是通过ORM来做的。
所以,首先需要有模型,在models.py中编写。
而真正保存到数据库中的是用户名、密码、手机号。
密码涉及到加密,后续不明文,以及权限的问题。
恰恰Django有默认的用户认证系统。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Django默认用户认证系统
• Django自带用户认证系统
• 它处理用户账号、组、权限以及基于cookie的用户会话。
• Django认证系统位置
• django.contrib.auth包含认证框架的核心和默认的模型。
• django.contrib.contenttypes是Django内容类型系统,它允许权限与你创建的模型关联。
• Django认证系统同时处理认证和授权
• 认证:验证一个用户是否它声称的那个人,可用于账号登录。
• 授权:授权决定一个通过了认证的用户被允许做什么。
• Django认证系统包含的内容
• 用户:用户模型类、用户认证。
• 权限:标识一个用户是否可以做一个特定的任务,MIS系统常用到。
• 组:对多个具有相同权限的用户进行统一管理,MIS系统常用到。
• 密码:一个可配置的密码哈希系统,设置密码、密码校验。
@@@@@@@@@@@@@@@@@@@@@@
即 在 External libraris–site packages–django–contrib–auth–models.py.
我们可以在自己的models.py中引入它其中需要的AbstractUser模块即可。
养成习惯好好看看这些类目录和作用。
而AbstractUser 本身又继承了两个父类, 在内部编写了 一些数据库user 表的主要字段,这也是为什么我们映射数据库之后,虽然没有表数据,但是表的字段都有了。
自我备忘, 类里面有下划线定义的方法,是私有。
创建用户必须传username,否则抛出异常。
# 可以说AbstractUser 大部分实现了用户注册的主题功能。
引入并将手机号添加字段,同时设置数据库后台所需
注释掉刚才的class User所有代码,运行一下,看看admin的login后台是怎样的,来知晓verbose_name等需求,后台用到,前台用不到。
现在分析解决刚才界面运行的报错问题。
HINT: Add or change a related_name argument to the definition for ‘User.user_permissions’ or ‘User.user_permissions’.
因为原先,数据库映射后能找到auth_user(External libraris–site packages–django–contrib–auth–models.py. ),现在相当于修改了它(因为继承了它的AbstractUser,并且添加了mobile)。
现在映射数据库是映射了users\models 这个ORM,
那么我现在告诉Django,我要映射的是哪个模型下的哪个ORM,哪个app下面的哪个model (即我要告诉Django, 现在要映射apps–users–models,同时让它知道我增加了mobile)。
那我们是不是可以改源码呢(External libraris–site packages–django–contrib–auth–models.py.** )?当然不建议,因为共同开发怎么玩呢,万一你的同组人员他们的源码都不改,而你改了, 你们也就冲突了 ,所以谁都不改源码。而且以后还要有更新。
解决这个问题的继续分析思路:
1.查看源码, 原类是写死的常量,swappable = ‘AUTH_USER_MODEL’
2. 看到常量,我们就要想到有Django中有全局的global变量 ,我们通过django–config–global_settings.py
搜到这个常量,你就看到它是 ‘auth.User’
这下明白了吧&#x