Django+xadmin打造线上教育平台知识点拾遗（三）Ericnan

1.4、自定义验证：

1）clean_%s(self)#clean_+要审查的那个字段

这种是验证单个字段的：

2）c.clean(self)#重写clean方法

这种可以验证多个字段：

demo：

2.1、创建ModelForm类：

ModelForm的自定义验证方法跟Form的自定义验证方法是一样的，内置字段名也基本一致，可以参考Form类的介绍，如：

数据以字典形式存于cleaned_data中，错误以字典形式存于errors中

ModelForm与Form的不同点：

ModelForm：字段不需要自己写，与model中定义的数据表相通、一致；验证数据通过后可以通过.save()直接保存

From：字段需要自己手动添加，只验证字段是否合法，数据保存之类需要手动保存

django项目，自定义404、500页面时，需要项目setting中配置：

DEBUG=False，

ALLOWED_HOSTS=['*',]（或ALLOWED_HOSTS=['127.0.0.1','localhost','192.168.1.155']等），表示允许访问本项目的地址配置完这两个，就可以自定义全局404、500页面了但，当DEBUG设置为False，此时setting中设置的静态文件路径，django均不会自动帮你配置，当HTML模板中需要用到setting中设置的静态文件路径时，一种是直接指定绝对路径：/static/image/xx.png；另一种是手动配置静态文件

路径：

首先，setting中配置是：

STATIC_URL='/static/'STATICFILES_DIRS=[os.path.join(BASE_DIR,'static'),]MEDIA_URL='/media/'MEDIA_ROOT=os.path.join(BASE_DIR,'media')然后需要在urls.py中配置：

DEBUG=True时，static路径在url下不需要配置

fromdjango.views.staticimportservefromMxOnline.settingsimportMEDIA_ROOT,STATICFILES_DIRSurlpatterns=[#处理静态文件,使用Django自带serve,传入setting中路径配置MEDIAROOT，让它根据路径找media下的文件re_path(r'^media/(P.*)',serve,{"document_root":MEDIA_ROOT}),#需要手动static_dirs路径，然后使用serve根据路径帮忙找到static下的文件re_path(r'^static/(P.*)',serve,{"document_root":STATICFILES_DIRS[0]}),]

好了，准备工作完成了，开始全局404、500页面操作

1、404页面：

views：

fromdjango.shortcutsimportrender_to_responsedefpag_not_found(request):#全局404处理函数response=render_to_response('404.html')response.status_code=404returnresponse

urls：

#全局404页面配置handler404='MxOnline.views.pag_not_found'

HTML页面：

2、500页面：

fromdjango.shortcutsimportrender_to_responsedefpage_error(request):#全局500处理函数fromdjango.shortcutsimportrender_to_responseresponse=render_to_response('500.html')response.status_code=500returnresponse

#全局500页面配置handler500='MxOnline.views.page_error'

注意：2.0版本，测试中发现：只要将debug设置为False，将自定义404、500（必须命名：404.html、500.html）页面导入到项目中的templates中，当url访问出错（404、500状态码）时，会自动调用404.html、500.html页面

sql注入的危害

sql注入案例（使用原生sql语句）：

select*fromuserwherename='${name}'

当用户输入name值为：'or1='1时，上述select代码变成：

select*fromuserwherename=''or1='1'

此时判断逻辑是符合要求的。类似这种就是sql注入。

xss跨站脚本攻击（CrossSiteScripting）的危害

xss攻击流程：

xss攻击防护

普通文本xxs攻击防护：

第二种是在Django后台导入escape过滤器(fromdjango.template.defaultfiltersimportescape)，然后将前端用户提交上来的数据进行转义(假如包含js等脚本代码)再存入数据库中，这样js脚本等也都会被转义，再从数据库中取出，然后到前端展示，即使使用了safe过滤器也不会被渲染为js脚本执行。

富文本xxs攻击防护：

对于富文本提交的数据，肯定会包含一些html标签操作(如：字体颜色、字体样式等)，这种要返回前端渲染展示时，就需要我们使用safe过滤器来将其标记为安全的，这样才能显示出富文本样式。这种情况就存在着xss脚本攻击的危险。但我们可以在后端对数据进行一些额为处理，比如：将需要的标签保留下来，把不需要的标签进行转义或移除掉。在python中，有一个库可以专门用来处理这个事情，具体解决方法如下：

1）首先安装bleach库：pipinstallbleach

bleach库是用来清理包含HTML格式字符串的库。他可以指定哪些标签需要保留，哪些标签是需要过滤掉的，也可以指定标签上哪些属性是可以保留，哪些属性是不需要的。demo：

ALLOWED_TAGS中，默认允许的标签：a、abbr、acronym、b、blockquote、code、em、i、li、ol、ul、strong

demo中方法介绍：

tag：表示允许哪些标签

attributes：表示标签中允许哪些属性

ALLOWED_TAGS：这个变量默认定义l一些允许的标签

ALLOWEND_ATTRIBUTES中：这个变量默认定义了一些允许的属性

bleach.clean方法：对提交的数据进行过滤

csrf跨站请求伪造（Cross-siterequestforgery）的危害

CSRF攻击流程：

CSRF攻击防范：

在form里面加上{%csrf_token%}

clickjacking攻击又称点击劫持攻击，是一种在网页中将恶意代码等隐藏在看似无害的内容（如按钮）之下，并诱惑用户点击的手段。

攻击场景：

1、给用户发邮件，诱惑用户点开，当用户点开的时候其实链入的是一购物网站等等

2、用户进入到一个网页中，里面包含一个非常有诱惑力的按钮A，但是这个按钮上面浮了一个透明的iframe标签，这个iframe标签加载的是另外一个网页，并且这个网页的某个按钮和原网页中的按钮重合。所以你在点击按钮A的时候，实际上点击的是通过iframe加载的另外一个网页的按钮。

clickjacking防护：

场景1的情形是无法避免的。而像场景2是可以避免的，只要设置该网站不允许使用iframe被加载到其他网页中就可以了。我们可以通过在响应头设置X-Framen-Option来设置这种操作。X-Frame-Option可以设置以下三个值：

DENY：不让任何网页使用iframe加载我这个页面SAMEORIGIN：只允许在相同域名下使用iframe加载我的页面ALLOW-FROMorigin：允许任何网页通过iframe加载我这个网页在Django中，使用中间件django.middleware.clickjacking.XFrameOptionsMiddleware可以帮我们堵上这个漏洞，这个中间件设置了X-Frame-Option为SAMEORIGIN，也就是只有在自己的网站下才可以使用iframe加载这个网页，这样就可以避免其他别有心机的网页去通过iframe加载我们的网页了。