一. Admin的配置
1.Admin基础设置
admin是django强大功能之一,它能够从数据库中读取数据,呈现在页面中,进行管理。默认情况下,它的功能已经非常强大,如果你不需要复杂的功能,它已经够用,但是有时候,一些特殊的功能还需要定制,比如搜索功能,下面这一系列文章就逐步深入介绍如何定制适合自己的admin应用。
<1> 在settings中设置Admin界面显示语言
LANGUAGE_CODE = 'en-us' #LANGUAGE_CODE = 'zh-hans'
<2> 认识ModelAdmin,管理界面的定制类,如需扩展特定的model界面需从该类继承。
<3>注册model类到admin的两种方式:
1) 使用register的方法
admin.site.register(Book,MyAdmin)
2) 使用register的装饰器
@admin.register(Book)
<4>掌握一些常用的设置技巧
list_display:指定要显示的字段
search_fields:指定搜索的字段
list_filter:指定列表过滤器
ordering:指定排序字段
list_per_page:设置每页显示多少条记录,默认是100条
list_editable:设置默认可编辑字段
fk_fields: 设置显示外键字段
date_hierarchy:按Admin自制表中的时间字段过滤
from django.contrib import admin from ORM_Study.models import * # Register your models here. # @admin.register(book)#----->单给某个表加一个定制 class MyAdmin(admin.ModelAdmin): list_display = ("title", "price","publish") search_fields = ("title","publish__name") list_filter = ("publish",) ordering = ("price",) list_per_page = 3 date_hierarchy ="date" admin.site.register(book,MyAdmin)
<5>Admin常用设置详解
在admin.py中只需要讲Mode中的某个类注册,即可在Admin中实现增删改查的功能,如:
admin.site.register(models.UserInfo)
但是,这种方式比较简单,如果想要进行更多的定制操作,需要利用ModelAdmin进行操作,如:
方式一: class UserAdmin(admin.ModelAdmin): list_display = ('user', 'pwd',) admin.site.register(models.UserInfo, UserAdmin) # 第一个参数可以是列表 方式二: @admin.register(models.UserInfo) # 第一个参数可以是列表 class UserAdmin(admin.ModelAdmin): list_display = ('user', 'pwd',)
ModelAdmin中提供了大量的可定制功能,如
1. list_display,列表时,定制显示的列。
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): list_display = ('user', 'pwd', 'xxxxx') def xxxxx(self, obj): return "xxxxx"
2. list_display_links,列表时,定制列可以点击跳转。
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): list_display = ('user', 'pwd', 'xxxxx') list_display_links = ('pwd',)
3. list_filter,列表时,定制右侧快速筛选。
4. list_select_related,列表时,连表查询是否自动select_related
5. list_editable,列表时,可以编辑的列
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): list_display = ('user', 'pwd','ug',) list_editable = ('ug',)
6. search_fields,列表时,模糊搜索的功能
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): search_fields = ('user', 'pwd')
7. date_hierarchy,列表时,对Date和DateTime类型进行搜索
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): date_hierarchy = 'ctime'
8 inlines,详细页面,如果有其他表和当前表做FK,那么详细页面可以进行动态增加和删除
class UserInfoInline(admin.StackedInline): # TabularInline extra = 0 model = models.UserInfo class GroupAdminMode(admin.ModelAdmin): list_display = ('id', 'title',) inlines = [UserInfoInline, ]
9 action,列表时,定制action中的操作
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): # 定制Action行为具体方法 def func(self, request, queryset): print(self, request, queryset) print(request.POST.getlist('_selected_action')) func.short_description = "中文显示自定义Actions" actions = [func, ] # Action选项都是在页面上方显示 actions_on_top = True # Action选项都是在页面下方显示 actions_on_bottom = False # 是否显示选择个数 actions_selection_counter = True
10 定制HTML模板
add_form_template = None change_form_template = None change_list_template = None delete_confirmation_template = None delete_selected_confirmation_template = None object_history_template = None
11 raw_id_fields,详细页面,针对FK和M2M字段变成以Input框形式
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): raw_id_fields = ('FK字段', 'M2M字段',)
12 fields,详细页面时,显示字段的字段
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): fields = ('user',)
13 exclude,详细页面时,排除的字段
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): exclude = ('user',)
14 readonly_fields,详细页面时,只读字段
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): readonly_fields = ('user',)
15 fieldsets,详细页面时,使用fieldsets标签对数据进行分割显示
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): fieldsets = ( ('基本数据', { 'fields': ('user', 'pwd', 'ctime',) }), ('其他', { 'classes': ('collapse', 'wide', 'extrapretty'), # 'collapse','wide', 'extrapretty' 'fields': ('user', 'pwd'), }), )
16 详细页面时,M2M显示时,数据移动选择(方向:上下和左右)
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): filter_vertical = ("m2m字段",) # 或filter_horizontal = ("m2m字段",)
17 ordering,列表时,数据排序规则
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): ordering = ('-id',) 或 def get_ordering(self, request): return ['-id', ]
18. radio_fields,详细页面时,使用radio显示选项(FK默认使用select)
radio_fields = {"ug": admin.VERTICAL} # 或admin.HORIZONTAL
19 form = ModelForm,用于定制用户请求时候表单验证
from app01 import models from django.forms import ModelForm from django.forms import fields class MyForm(ModelForm): others = fields.CharField() class Meta: model = models = models.UserInfo fields = "__all__" @admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): form = MyForm
20 empty_value_display = "列数据为空时,显示默认值"
@admin.register(models.UserInfo) class UserAdmin(admin.ModelAdmin): empty_value_display = "列数据为空时,默认显示" list_display = ('user','pwd','up') def up(self,obj): return obj.user up.empty_value_display = "指定列数据为空时,默认显示"
二. Cookie和Session
1.Cookie和Session的基本介绍
cookie不属于http协议范围,由于http协议无法保持状态,但实际情况,我们却又需要“保持状态”,因此cookie就是在这样一个场景下诞生。cookie的工作原理是:由服务器产生cookie内容,浏览器收到请求响应后保存在本地;当浏览器再次访问该服务器时,浏览器会自动带上cookie,这样服务器就能通过cookie的内容来判断这个是“谁”。简明来说,基于http协议的无状态特征,服务器根本就不知道访问者是“谁”,那么上述的cookie就起到桥接的作用,我们可以给每个客户端的cookie分配一个唯一的id,这样用户在访问时,通过cookie,服务器就知道来的人是“谁”,然后我们再根据不同的cookie的id,在服务器上保存一段时间的私密资料,如“账号密码”等等。cookie虽然在一定程度上解决了“保持状态”的需求,但是由于cookie本身最大支持4096字节,以及cookie本身保存在客户端,可能被拦截或窃取,因此就需要有一种新的东西,它能支持更多的字节,并且他保存在服务器,有较高的安全性,这便出现了session。
Set-Cookie: NAME=VALUE;Expires/Max-age=DATE;Path=PATH;Domain=DOMAIN_NAME;SECURE
参数意义:
- NAME:cookie的名字。
- VALUE:cookie的值。
- Expires:cookie的过期时间。
- Path:cookie作用的路径。
- Domain:cookie作用的域名。
- SECURE:是否只在https协议下起作用。
总结:cookie弥补了http无状态的不足,让服务器知道来的人是“谁”;但是cookie以文本的形式保存在本地,自身安全性较差;所以我们就通过cookie识别不同的用户,对应的在session里保存私密的信息以及超过4096字节的文本。
经过前面的学习我们已经有能力制作一个登陆页面,在验证了用户名和密码的正确性后跳转到后台的页面。但是测试后也发现,如果绕过登陆页面,直接输入后台的url地址也可以直接访问。这个显然是不合理的。其实我们缺失的就是cookie和session配合的验证。有了这个验证过程,我们就可以实现和其他网站一样必须登录才能进入后台页面了。
先说一下这种认证的机制。每当我们使用一款浏览器访问一个登陆页面的时候,一旦我们通过了认证。服务器端就会发送一组随机唯一的字符串(假设是123abc)到浏览器端,这个被存储在浏览器端的东西就叫cookie。而服务器端也会自己存储一下用户当前的状态,比如login=true,username=hahaha之类的用户信息。但是这种存储是以字典形式存储的,字典的唯一key就是刚才发给用户的唯一的cookie值。那么如果在服务器端查看session信息的话,理论上就会看到如下样子的字典
{'123abc':{'login':true,'username:hahaha'}}
因为每个cookie都是唯一的,所以我们在电脑上换个浏览器再登陆同一个网站也需要再次验证。那么为什么说我们只是理论上看到这样子的字典呢?因为处于安全性的考虑,其实对于上面那个大字典不光key值123abc是被加密的,value值{'login':true,'username:hahaha'}在服务器端也是一样被加密的。所以我们服务器上就算打开session信息看到的也是类似与以下样子的东西{'123abc':dasdasdasd1231231da1231231}
借用一张别的大神画的图,可以更直观的看出来cookie和session的关系
cookie和session的应用实例:
<1>先在templates目录下创建两个html,login.html负责登录页面,backend页面代表后台页面
/*---------------------------login.html-----------------------------*/ <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> </head> <body> <div class="container"> <form action="login.html" method="post"> <div class="form-group"> <label class="sr-only">username</label> <input type="text" class="form-control" name="username" placeholder="用户名"/> </div> <div class="form-group"> <label class="sr-only">Password</label> <input type="password" class="form-control" name="passwd" placeholder="密码"/> </div> <div class="form-group"> <input class="btn btn-primary" type="submit" value="提交"> </div> </form> </div> </body> </html> /*---------------------------backend.html-----------------------*/ <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> </head> <body> <div class="container"> <h2>cookie 内容是 {{ cookie_content }}</h2> <h2>session 内容是 {{ session_content }}</h2> <h2>登录用户名 :{{ username }}</h2> </div> </body> </html>
<2> 在应用下的views.py文件,编写代码逻辑部分
def login(request): print("COOKIES", request.COOKIES) print("SESSION", request.session) #------------首次进入login.html页面cookies和session打印内容 #COOKIES {'csrftoken': 'x8OVNJyVE7SMVgPXTLSoJiNNr6KSTG7CyOwXHoKhBKsFwlCyCXh3UVfHExheoA0g', 'sessionid': '9s3jx5sb5euzdla2d1aq44yrehvun1e2'} #SESSION <django.contrib.sessions.backends.db.SessionStore object at 0x00000213ADA15DA0> if request.method == "POST": username = request.POST['username'] pwd = request.POST['passwd'] print('================================') if username == 'abc' and pwd == '123': #----------------cookie单独使用--------------------- #cookie单独使用时,设置cookiea内部字典的内容 # ret=redirect('/backend/') # ret.set_cookie("username",username) # return ret #----------cookie和sessions结合使用----------------- # 设置session内部的字典内容 request.session['is_login'] = 'true' request.session['username'] = 'abc' #登录成功就将url重定向到后台的url return redirect('/backend/') # 登录不成功或第一访问就停留在登录页面 return render(request,'login.html') def backend(request): print("COOKIES", request.COOKIES) print("SESSION", request.session) #-----------------------cookie单独使用------------------ # if request.COOKIES.get("username", None): # username = request.COOKIES.get("username", None) # cookie_content = request.COOKIES # return render(request, "backend.html", locals()) # #返回值: # # cookie内容是{'username': 'abc'} # # session 内容是 # # 登录用户名 :abc #-----------------cookie和session结合使用----------------- """ 这里必须用读取字典的get()方法把is_login的value缺省设置为False, 当用户访问backend这个url先尝试获取这个浏览器对应的session中的 is_login的值。如果对方登录成功的话,在login里就已经把is_login 的值修改为了True,反之这个值就是False的 """ is_login = request.session.get('is_login', False) # 如果为真,就说明用户是正常登陆的 if is_login: # 获取字典的内容并传入页面文件 # 或者用if request.session.get("is_login",None): cookie_content = request.COOKIES session_content = request.session username = request.session['username'] return render(request, 'backend.html', { 'cookie_content': cookie_content, 'session_content': session_content, 'username': username }) #返回的值: # cookie 内容是 {'csrftoken': 'x8OVNJyVE7SMVgPXTLSoJiNNr6KSTG7CyOwXHoKhBKsFwlCyCXh3UVfHExheoA0g', 'sessionid': '9s3jx5sb5euzdla2d1aq44yrehvun1e2'} # session内容是 < django.contrib.sessions.backends.db.SessionStore object at 0x000001BF7D04DDD8 > # 登录用户名 :abc else: """ 如果访问的时候没有携带正确的session, 就直接被重定向url回login页面 """ return redirect('/login/')
<3>编辑urls.py文件,设置函数与页面的绑定关系
from django.contrib import admin from django.urls import path from ORM_Study import views from django.conf.urls import url urlpatterns = [ #path('admin/', admin.site.urls), url('^login/',views.login,name='login'), url('^backend/',views.backend,name='backend'), ]
<4>最后打开浏览器直接访问/backend/页面,检测是否直接就被重定向到了/login/页面
<5>总结
从上述步骤中我们看到有一下几点:
(1)login页面正确登录的话,后台页面可以获取到浏览器携带的cookie的。
(2)返回的sessionid其实就是cookie值
(3)session的内容是加密的,从客户端获取不到session的内容
(4)服务端可以通过预设的key值取出session的内容并打印到前段
(5)django的session默认是存储在数据库里的,我们可以到数据库查看一下真正session内容,在表Django_session里
(6)session的好处:客户端只有cookie值,始终没有用户信息
(7)session依赖于cookie,cookie保存在浏览器,session保存在服务器端。
<6>cookie和session的知识点总结:
操作cookie:
获取cookie:request.COOKIES[key]
设置cookie:response.set_cookie(key,value)
操作session(session默认在服务器端保存15天):
获取session:request.session[key] 设置session:reqeust.session[key] = value 删除session:del request.session[key] 设置session时效: request.session.set_expiry(value) * 如果value是个整数,session会在这些秒数后失效。 * 如果value是个datatime或timedelta,session就会在这个时间后失效。 * 如果value是0,用户关闭浏览器session就会失效。 * 如果value是None,session会依赖全局session失效策略。
>>>>>>>>>待续