赞
踩
昨天我们为了登录admin,通过命令创建了超级用户,你是不是有个疑问——这创建的超级用户的信息是存放在哪里了呢
这就想到了我们映射数据库时,Django自动创建的一些表(这也是之前进行数据库迁移时没有提到的那些表)!!!
如上图就是Django自带的auth系统对应的表,也就是存放了之前创建的超级用户信息的表(也也就是之前没有提及到的数据库迁移生成的表~)
注意点:上面所示表中有多对多表关系生成的中间表,而Django很人性化的一点是:如果是多对多关系产生的中间表,其命名方式是主表在前,从表在后!比如auth_group_permissions表,其中auth_group就是主表,auth_permissions就是从表,如果要进行两表关联,则从auth_group到auth_permissions是正向!!!
从上图表的名称我们就能看出,
auth_user,auth_group,auth_permission分别
存放了用户,用户组,权限的信息表.
另外三张表就是多对多关系的中间表
auth模块是Django提供的标准权限管理系统,可以提供用户身份认证, 用户组和权限管理这些功能,那么我们就可以使用它来完善我们之前的一些小型项目;
auth可以和admin模块配合使用, 快速建立网站的管理系统;
在INSTALLED_APPS中添加’django.contrib.auth’使用该APP, auth模块默认启用。
(我们可以查看此表,发现之前创建的超级用户信息就在这哦!不过密码是经过HASH加密了~)
User对象顾名思义即为表示用户的对象,里面的属性包括以上几条:
创建好对象后,django会自动生成表,表名为auth_user,包含以上字段。
User模型常用属性和方法如下:
username
用户名。必选。少于等于30个字符。 用户名可以包含字母、数字、_、@、+、.和- 字符。
first_name
可选。 少于等于30个字符。
last_name
可选。少于30个字符。
可选。邮箱地址。
password
必选。 密码的哈希及元数据。(Django 不保存原始密码)。原始密码可以无限长而且可以包含任意字符。参见密码相关的文档。
groups
与Group 之间的多对多关系。
user_permissions
与Permission 之间的多对多关系。
is_staff
布尔值。指示用户是否可以访问Admin 站点(即是否是admin的管理员)。
is_active
布尔值。指示用户的账号是否激活。
is_superuser
布尔值。是否是超级用户。
last_login
用户最后一次登录的时间。
date_joined
账户创建的时间。当账号创建时,默认设置为当前的date/time。
is_authenticated
is_anonymous
set_password(raw_password)
check_password(raw_password)
has_perm(perm)
has_perms(perm_list)
from django.contrib.auth.models import User
User.objects.create_user(username, email, password)
(比如前面的注册登录小案例,我们可以通过更改入库的代码,来实现user用户的创建~)
因为创建的user用户的password是加密之后入库的,无法直接对比来判断用户是否存在,所以Django就自带了authenticate函数来进行用户认证。
导入所用函数:
from django.contrib.auth import authenticate
使用:
user = authenticate(username=username, password=password)
认证用户的密码是否有效, 若有效则返回代表该用户的user对象, 若无效则返回None(注意:该方法不检查is_active标志位.)
(比如前面的注册登录小案例,我们可以通过更改原本查询的代码,来实现user用户的认证~)
补充:现在前端验证是否登录的话直接user.username获取即可!(如果登录则会获取到登录的用户的名字;未登录则获取不到。)
导入所用函数:
from django.contrib.auth import login
使用(login向session中添加SESSION_KEY, 便于对用户进行跟踪):
login(request, user)
注意——login不进行认证,也不检查is_active标志位, 所以一般和authenticate配合使用:
user = authenticate(username=username, password=password)
if user is not None:
if user.is_active:
login(request, user)
(比如前面的注册登录小案例,我们可以通过更改原本设置session的代码,来实现登录~)
导入所用函数:
from django.contrib.auth import logout
使用(logout会移除request中的user信息, 并刷新session):
@login_required修饰器修饰的view函数会先通过session key检查是否登录, 已登录用户可以正常的执行操作, 未登录用户将被重定向到login_url指定的位置;
若未指定login_url参数, 则重定向到settings.LOGIN_URL。
导入使用的函数:
from django.contrib.auth.decorators import login_required
使用:
@login_required(login_url=‘/accounts/login/’)
def my_view(request):
…
按照常规逻辑来说——你没登录,网站给你跳转到登录页面要求你登录,那么在你登录之后应该再给你跳转回去之前的页面。下面来带你实现:
我们使用⑤发现,比如我们未登录状态下访问一个页面,它会立马重定向到我们指定的登录页面。
现在有个需求,我们在登录之后,能够让页面回到我们先前访问的那个页面。观察URL发现,跳转到登录页面的URL里携带一个参数next,值为跳转的源路径。所以获取一下即可!
(比如前面的注册登录小案例,我们只需要在登录业务逻辑中进行判断,如果可以获取到index参数,那就说明我们是因为权限不够没有登录而跳转过来的;如果获取不到Index参数,那就说明我们是正常登录!)
is_authenticated
通过在视图函数中利用User对象的is_authenticated方法进行判断用户是否登录。如:
django.contrib.auth.models.Group定义了用户组的模型, 每个用户组拥有id和name两个字段, 该模型在数据库被映射为auth_group数据表。
User对象中有一个名为groups的多对多字段, 多对多关系由auth_user_groups数据表维护。Group对象可以通过user_set反向查询用户组中的用户。
我们可以通过创建删除Group对象来添加或删除用户组:
导入使用的函数:
from django.contrib.auth.models import Group
group = Group.objects.create(name=group_name)
group.save()
group.delete()
我们可以通过标准的多对多字段操作管理用户与用户组的关系:
注意:下述的user是获取到的user实例,group也是获取到的group实例。比如:
user = User.objects.get(id=1)
group = Group.objects.get(id=1)
用户加入用户组:user.groups.add(group)或group.user_set.add(user)
用户退出用户组:user.groups.remove(group)或group.user_set.remove(user)
用户退出所有用户组:user.groups.clear()
用户组中所有用户退出组:group.user_set.clear()
Django的auth系统提供了模型级的权限控制, 即可以检查用户是否对某个数据表拥有增(add), 改(change), 删(delete)权限。
auth系统无法提供对象级的权限控制, 即检查用户是否对数据表中某条记录拥有增改删的权限。如果需要对象级权限控制可以使用django-guardian。假设在博客系统中有一张article数据表管理博文, auth可以检查某个用户是否拥有对所有博文的管理权限, 但无法检查用户对某一篇博文是否拥有管理权限。
查看数据库中auth_permission这张表,在里面有所有的表的一些操作权限,这些是在表创建的同是添加进来的数据(你会发现对应表的权限的名字是由其模型类名构成的!)
知识补给站:
每个模型默认拥有增(add), 改(change), 删(delete)权限。在django.contrib.auth.models.Permission模型中保存了项目中所有权限。
该模型在数据库中被保存为auth_permission数据表。每条权限拥有id ,name , content_type_id, codename四个字段。
user.has_perm方法用于检查用户是否拥有操作某个模型的权限:
user.has_perm(‘blog.add_article’)
user.has_perm(‘blog.change_article’)
user.has_perm(‘blog.delete_article’)
上述语句检查用户是否拥有blog这个app中article模型的添加权限, 若拥有权限则返回True。
has_perm仅是进行权限检查, 即用户没有权限它也不会阻止用户执行相关操作。
permission_required修饰器可以代替has_perm并在用户没有相应权限时重定向到登录页或者抛出异常。
@permission_required(appname.codename(权限名称))
给名为blog的app当中的博客添加视图设置权限:
from django.contrib.auth.decorators import permission_required
@permission_required('blog.add_blogmodel') # 给对应的视图设置权限,让除了超级用户之外的用户丧失设置的权限!可以依此方法设置任意四种权限!
def add_get_post(request):
...
这样的话只有被设置拥有此权限的用户才可访问此视图函数对应的前端页面(注意:如果是超级用户是拥有所有权限的)。
哪怕你登录了普通用户会发现也访问失败,它会自动给你跳转到你settings.py文件中设置的权限不足而跳转到的页面里!(此处为登录页面。)
User和Permission通过多对多字段user.user_permissions关联,在数据库中由auth_user_user_permissions数据表维护。
添加权限: user.user_permissions.add(permission)
删除权限: user.user_permissions.delete(permission)
清空权限: user.user_permissions.clear()
通过观察auth_permission权限表可知:如果你要给指定用户添加某个权限,那实现的方法就是通过用户信息表auth_user和权限信息表auth_permissons由于多对多关系产生的中间表auth_user_user_permissions的操作来完成,即让指定的用户与要添加的权限产生关系!(多对多表关系的添加)
①注意:要导入权限表!
②图个方便,直接找个视图在里面进行操作:
③现在如果访问博客添加页面,哪怕你登录了普通用户(id为1)会发现也可以访问,这就说明咱给这个普通用户成功添加了添加权限!
用户拥有他所在用户组的权限, 使用用户组管理权限是一个更方便的方法。Group中包含多对多字段permissions, 在数据库中由auth_group_permissions数据表维护。
添加权限: group.permissions.add(permission)
删除权限: group.permissions.delete(permission)
清空权限: group.permissions.clear()
如何理解?试想上面给少数用户添加权限不是很麻烦,但是如果要给好多的用户添加权限岂不是很麻烦,所以又了给组添加权限的概念。我们可以将删除权限设置成一个组;查看权限设置成一个组…如果来了几十个需要添加查看权限的用户,只需将它们都扔进查看权限那个组即可!而且如果以后要对拥有查看权限的用户的权限进行改动或者升级,这样也非常方便!
组信息表的结构:
①注意:导入组信息表
②通过观察组信息表的结构创建组:
③为新创建的组添加权限(此处是添加了添加权限!):
④举例将一个用户扔进组中,说明如何将用户放进具有权限的组中:
⑤现在如果访问博客添加页面,哪怕你登录了普通用户(id为3)会发现也可以访问,这就说明咱给这个普通用户成功添加了添加权限!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。