struts2的校验

struts2的校验相关知识

• SpringMVC【校验器、统一处理异常、RESTful、拦截器】

  前言 本博文主要讲解的知识点如下： 校验器 统一处理异常 RESTful 拦截器 Validation 在我们的Struts2中，我们是继承ActionSupport来实现校验的...它有两种方式来实现校验的功能 手写代码 XML配置 这两种方式也是可以特定处理方法或者整个Action的 而SpringMVC使用JSR-303（javaEE6规范的一部分）校验规范，springmvc使用的是Hibernate Validator（和Hibernate的ORM无关） 快速入门 导入jar包 配置校验器 <!-- 校验器 --> <bean id="validator" class="org.springframework
• Spring 校验器(Validator)

  Spring校验器，参数校验从此简单。 应用在执行业务逻辑之前，必须通过校验保证接受到的输入数据是合法正确的，但很多时候同样的校验出现了多次，在不同的层，不同的方法上，导致代码冗余，浪费时间，违反DRY原则。 每一个控制器都要校验 过多的校验参数会导致代码太长 代码的复用率太差，同样的代码如果出现多次，在业务越来越复杂的情况下，维护成本呈指数上升。 可以考虑把校验的代码封装起来，来解决出现的这些问题。 JSR-303 JSR-303是Java为Bean数据合法性校验提供的标准框架，它定
• Hibernate数据校验简介

  我们在业务中经常会遇到参数校验问题，比如前端参数校验、Kafka消息参数校验等，如果业务逻辑比较复杂，各种实体比较多的时候，我们通过代码对这些数据一一校验，会出现大量的重复代码以及和主要业务无关的逻辑。Spring MVC提供了参数校验机制，但是其底层还是通过Hibernate进行数据校验，所以有必要去了解一下Hibernate数据校验和JSR数据校验规范。 JSR数据校验规范 Java官方先后发布了JSR303与JSR349提出了数据合法性校验提供的标准框架：BeanValidator，BeanValidator框架中，用户通过在Be
• 更加灵活的参数校验，Spring-boot自定义参数校验注解

  上文如何在spring-boot中进行参数校验我们讨论了如何使用@Min、@Max等注解进行参数校验，主要是针对基本数据类型和级联对象进行参数校验的演示，但是在实际中我们往往需要更为复杂的校验规则，比如注册用户的密码和确认密码进行校验，这个时候基本的注解就无法满足我们的要求了，需要去按照业务需求去自定义注解进行校验 元注解 在自定义注解之前我们有必要了解一些元注解，元注解就是在注解上的注解，可以对一个注解进行配置，元注解包括@Retention、@Target、@Document、@Inherited四种 @Re

struts2的校验相关课程

• 校招计算机基础必考八股文，7天快速复盘 助力进大厂 对大多数人来说，校招，是相对容易进大厂的机会，也是奠定职场生涯的重要起点。本课程针对准应届生而设，从计算机网络、操作系统、计算机原理、算法与数据结构、设计模式、数据库等经典基础知识，到初次求职的软技能，快速提升大厂重视的后端素养，斩获心仪校招offer。

  讲师：咚咚呛 中级 290人正在学习

• 前端模拟面试，给你真实的求职体验和面试经验 知己知彼，百战不殆。面试是求职者与面试官双方的交锋，每个问题都有含义，每个回答都能影响你的面试结果。如何理解面试问题背后的内涵，如何给出有效回答，如何适当展示自己的优势？本课程邀请5位不同背景的前端求职者，真实还原面试过程，并复盘面试表现，更直观、更有效地帮助大家提升面试技巧，优化面试表现。

  讲师：双越 入门 108人正在学习

• 为毕业生打造的全栈课 一站解决毕设问题（选题/毕设/论文/答辩） 专为毕业生打造，助你高效、高质量完成毕设作品，解决毕业头等大事。课程全面梳理毕设流程，并精准定位每个环节的重点难点、完成技巧，扫清毕设难题。采用主流、企业级技术栈，祝你完成毕设，直面校招。

  讲师：然冬 入门 311人正在学习

struts2的校验相关教程

• 3.1 参数校验 参数校验是一种有效且方便的措施，一般在控制层进行校验。我们举几个比较常见的校验例子：整数校验，如判断 id 是否为整数，非整数则报错，可以有效的抑制上面案例中的 SQL 注入；正则校验，如判断用户名是否符合规则，不能含有.，首字符必须是英文字符等。参数校验可以将非法参数拦截在外，保证 SQL 接触参数的合法性，而在实际应用中，参数校验几乎是一种标配。如果你在实际开发中，有用到参数校验，那么你有意识到它的重要性吗？如果你没有意识到，那么此时是否可以思考一下如何去让你的校验更加安全、有效。
• 4.3 编写校验方法 获取到了注解以及其内容，我们就可以编写一个校验方法，来校验字段长度是否合法了。我们在Student类中新增一个checkFieldLength()方法，用于检查字段长度是否合法，如果不合法则抛出异常。完整实例如下：import java.lang.reflect.Field;public class Student { // 标注注解 @Length(min = 2, max = 5, message = "昵称的长度必须在2~5之间") private String nickname; public Student(String nickname) { this.setNickname(nickname); } public String getNickname() { return nickname; } public void setNickname(String nickname) { this.nickname = nickname; } public void checkFieldLength(Student student) throws IllegalAccessException { // 遍历所有Field for (Field field: student.getClass().getDeclaredFields()) { // 获取注解 Length annotation = field.getAnnotation(Length.class); if (annotation != null) { // 获取字段 Object o = field.get(student); if (o instanceof String) { String stringField = (String) o; if (stringField.length() < annotation.min() || stringField.length() > annotation.max()) { throw new IllegalArgumentException(field.getName() + ":" + annotation.message()); } } } } } public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { Student student = new Student("小"); student.checkFieldLength(student); }}运行结果：Exception in thread "main" java.lang.IllegalArgumentException: nickname昵称的长度必须在2~5之间 at Student.checkFieldLength(Student.java:32) at Student.main(Student.java:41)运行过程如下：
• 1.5 增加校验属性的Block 让方法对传入的Block值进行校验class Personenddef add_checked_attribute(klass, attribute, &validation) klass.class_eval do define_method "#{attribute}=" do |value| raise 'Invalid attribute！' unless validation.call(value) instance_variable_set("@#{attribute}", value) end define_method attribute do instance_variable_get "@#{attribute}" end endendadd_checked_attribute(Person, :age) {|age| age >= 18}add_checked_attribute(Person, :sex) {|age| age == 'man'}me = Person.newme.age = 18me.sex = 'man'puts me.ageputs me.sex# ---- 输出结果 ----18man当我们赋予属性的值不满足条件的时候会抛出异常。me = Person.newme.sex = 'woman'# ---- 输出结果 ----Invalid attribute！ (RuntimeError)
• 表单校验 本篇主要介绍使用 JavaScript 进行表单验证。表单验证并不是 JavaScript 提供的某种特性，而是结合各种特性达到的一种目的，是需求的产物。所有线上产品的表单几乎都有验证，如注册时要求“用户名 6-16 位”，验证会由 JavaScript 来完成，通常为了安全性和准确性，服务端会再次做一遍验证。
• 2.2 使用 Form 校验数据 使用表单校验传过来的数据是否合法，这大概是使用 Form 类的优势之一。比如前面的实验2中，我们完成了一个对输入密码字段的校验，要求输入的密码必须含有大小写以及数字，三者缺一不可。在 Form 中，对于使用 Form 校验数据，我们会用到它的如下几个方法：Form.clean()：默认是返回一个 cleaned_data。对于 cleaned_data 的含义，后面会在介绍 Form 属性字段时介绍到，我们看源码可知，clean() 方法只是返回 Form 中得到的统一清洗后的正确数据。# 源码位置：django/forms/forms.py# ...@html_safeclass BaseForm: # ... def clean(self): """ Hook for doing any extra form-wide cleaning after Field.clean() has been called on every field. Any ValidationError raised by this method will not be associated with a particular field; it will have a special-case association with the field named '__all__'. """ return self.cleaned_data # ...# ...我们继续在前面的命令行上完成实验。上面输入的数据中由于 password 字段不满足条件，所以得到的cleaned_data 只有 name 字段。 想要调用 clean() 方法，必须要生成 cleaned_data 的值，而要生成cleaned_data 的值，就必须先调用 full_clean() 方法，操作如下：>>> login_bound.full_clean()>>> login_bound.clean(){'name': 'test11'}>>> login_bound.cleaned_data{'name': 'test11'}来从源代码中看看为什么要先调用 full_clean() 方法才有 cleaned_data 数据：# 源码位置：django/forms/forms.py@html_safeclass BaseForm: # ... def full_clean(self): """ Clean all of self.data and populate self._errors and self.cleaned_data. """ self._errors = ErrorDict() if not self.is_bound: # Stop further processing. return self.cleaned_data = {} # If the form is permitted to be empty, and none of the form data has # changed from the initial data, short circuit any validation. if self.empty_permitted and not self.has_changed(): return self._clean_fields() self._clean_form() self._post_clean() def _clean_fields(self): for name, field in self.fields.items(): # value_from_datadict() gets the data from the data dictionaries. # Each widget type knows how to retrieve its own data, because some # widgets split data over several HTML fields. if field.disabled: value = self.get_initial_for_field(field, name) else: value = field.widget.value_from_datadict(self.data, self.files, self.add_prefix(name)) try: if isinstance(field, FileField): initial = self.get_initial_for_field(field, name) value = field.clean(value, initial) else: value = field.clean(value) self.cleaned_data[name] = value if hasattr(self, 'clean_%s' % name): value = getattr(self, 'clean_%s' % name)() self.cleaned_data[name] = value except ValidationError as e: self.add_error(name, e) # ...可以看到，全局搜索 cleaned_data 字段，可以发现 cleaned_data 的初始赋值在 full_clean() 方法中，然后会在 _clean_fields() 方法中对 Form 中所有通过校验的数据放入到 cleaned_data，形成相应的值。Form.is_valid()：这个方法就是判断 Form 表单中的所有字段数据是否都通过校验。如果有一个没有通过就是 False，全部正确才是 True：>>> from hello_app.views import LoginForm>>> from django import forms>>> login_bound = LoginForm({'name': 'test11', 'password': '111111', 'save_login': False})>>> login_bound.is_valid()>>> login_bound.clean(){'name': 'test11'}>>> login_bound.cleaned_data{'name': 'test11'}注意：我们发现在使用了 is_valid() 方法后，对应 Form 实例的 cleaned_data 属性值也生成了，而且有了数据。参看源码可知 is_valid() 方法同样调用了 full_clean() 方法：# 源码位置：django/forms/forms.py# ...@html_safeclass BaseForm: # ... @property def errors(self): """Return an ErrorDict for the data provided for the form.""" if self._errors is None: self.full_clean() return self._errors def is_valid(self): """Return True if the form has no errors, or False otherwise.""" return self.is_bound and not self.errors # ... # ...在看到这段源代码的时候，我们可以这样考虑下，如果想让上面的 is_valid() 方法调用后并不继续调用 full_clean() 方法，这样 cleaned_data 就不会生成，再调用 clean() 方法就会报错。那么我们如何做呢？很简单，只需要控制 if self._errors is None 这个语句不成立即可：(django-manual) [root@server first_django_app]# python manage.py shellPython 3.8.1 (default, Dec 24 2019, 17:04:00) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linuxType "help", "copyright", "credits" or "license" for more information.(InteractiveConsole)>>> from hello_app.views import LoginForm>>> from django import forms>>> login_bound = LoginForm({'name': 'test11', 'password': 'SPYinx1111', 'save_login': False})>>> print(login_bound._errors)None>>> login_bound._errors=[]>>> login_bound.is_valid()True>>> login_bound.cleaned_dataTraceback (most recent call last): File "<console>", line 1, in <module>AttributeError: 'LoginForm' object has no attribute 'cleaned_data'>>> login_bound.clean()Traceback (most recent call last): File "<console>", line 1, in <module> File "/root/.pyenv/versions/django-manual/lib/python3.8/site-packages/django/forms/forms.py", line 430, in clean return self.cleaned_dataAttributeError: 'LoginForm' object has no attribute 'cleaned_data'看到了源码之后，我们要学会操作，学会分析一些现象，然后动手实践，这样才会对 Django 的源码越来越熟悉。Form.errors：它是一个类属性，保存的是校验错误的信息。该属性还有一些有用的方法，我们在下面实践中熟悉：(django-manual) [root@server first_django_app]# python manage.py shellPython 3.8.1 (default, Dec 24 2019, 17:04:00) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linuxType "help", "copyright", "credits" or "license" for more information.(InteractiveConsole)>>> from hello_app.views import LoginForm>>> from django import forms>>> login_bound = LoginForm({'name': 'te', 'password': 'spyinx1111', 'save_login': False})>>> login_bound.errors{'name': ['账号名最短4位'], 'password': ['密码需要包含大写、小写和数字']}>>> login_bound.errors.as_data(){'name': [ValidationError(['账号名最短4位'])], 'password': [ValidationError(['密码需要包含大写、小写和数字'])]}# 中文编码>>> login_bound.errors.as_json()'{"name": [{"message": "\\u8d26\\u53f7\\u540d\\u6700\\u77ed4\\u4f4d", "code": "min_length"}], "password": [{"message": "\\u5bc6\\u7801\\u9700\\u8981\\u5305\\u542b\\u5927\\u5199\\u3001\\u5c0f\\u5199\\u548c\\u6570\\u5b57", "code": ""}]}'看到最后的 as_json() 方法，发现转成 json 的时候中文乱码，这个输出的是 unicode 编码结果。第一眼看过去特别像 json.dumps() 的包含中文的情况。为了能解决此问题，我们先看源码，找到原因：# 源码位置：django/forms/forms.py@html_safeclass BaseForm: # ... @property def errors(self): """Return an ErrorDict for the data provided for the form.""" if self._errors is None: self.full_clean() return self._errors # ... def full_clean(self): """ Clean all of self.data and populate self._errors and self.cleaned_data. """ self._errors = ErrorDict() # ... # ... # 源码位置: django/forms/utils.py@html_safeclass ErrorDict(dict): """ A collection of errors that knows how to display itself in various formats. The dictionary keys are the field names, and the values are the errors. """ def as_data(self): return {f: e.as_data() for f, e in self.items()} def get_json_data(self, escape_html=False): return {f: e.get_json_data(escape_html) for f, e in self.items()} def as_json(self, escape_html=False): return json.dumps(self.get_json_data(escape_html)) # ...可以看到，errors 属性的 as_json() 方法最后调用的就是 json.dumps() 方法。一般要解决它的中文输出显示问题，只需要加上一个 ensure_ascii=False 即可。这里我们也只需要改下源码：(django-manual) [root@server first_django_app]# vim ~/.pyenv/versions/django-manual/lib/python3.8/site-packages/django/forms/utils.py# ... def as_json(self, escape_html=False): return json.dumps(self.get_json_data(escape_html), ensure_ascii=False)# ...然后我们再次进行 shell 命令行下，执行刚才的命令，发现中文输出已经正常了。django-manual) [root@server first_django_app]# python manage.py shellPython 3.8.1 (default, Dec 24 2019, 17:04:00) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linuxType "help", "copyright", "credits" or "license" for more information.(InteractiveConsole)>>> from hello_app.views import LoginForm>>> from django import forms>>> login_bound = LoginForm({'name': 'te', 'password': 'spyinx1111', 'save_login': False})>>> login_bound.errors{'name': ['账号名最短4位'], 'password': ['密码需要包含大写、小写和数字']}>>> login_bound.errors.as_json()'{"name": [{"message": "账号名最短4位", "code": "min_length"}], "password": [{"message": "密码需要包含大写、小写和数字", "code": ""}]}'>>>
• 1. 深入 Django 中 CSRF 校验过程 上一节中提到了，针对 CSRF 攻击有效的解决方案是在网页上添加一个随机的校验 token 值，我们前面的登录的模板页面中添加的 {% csrf_token %}，这里正好对应着一个随机值。我们拿之前的登录表单来进行观察，会发现这样几个现象：网页上隐藏的 csrf_token 值会在每次刷新时变化；对应在请求和响应头部的 cookie 中的 csrftoken值却一直不变；这样子我们对应会产生几个思考问题：为什么网页上的 token 值会变，而 cookie 中的 token 则一直不变？整个 token 的校验过程是怎样的，有密码？如果有密码，密码存在哪里？今天我们会带着这两个问题，查看下 Django 内部源码，找到这些问题的代码位置。我可能不会很完整的描述整个代码运行的逻辑，因为篇幅不够，而且细节太多，容易迷失在代码的海洋里。首先毋庸置疑的第一步是找我们在 settings.py 中设置的 CSRF 中间件：MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware',]我们在上一讲中提到过中间件类的两个函数：process_request() 和 process_response()。而在 CSRF 中间件文件中还有一个方法：process_view()。中间类比较完整的处理流程示意图如下所示，可以看到中间件的 process_view() 方法如果返回 None，则会执行下一个 中间件的 process_view() 方法。一旦它返回 HttpResponse 实例，则直接跳过视图函数到达最后一个中间件的 process_response() 方法中。我们来关注下 django.middleware 目录下的 csrf.py 文件，所有的答案都在这里可以找到。首先看最核心的中间件类：# 源码位置：django/middleware/csrf.py# ...class CsrfViewMiddleware(MiddlewareMixin): def _accept(self, request): # Avoid checking the request twice by adding a custom attribute to # request. This will be relevant when both decorator and middleware # are used. request.csrf_processing_done = True return None def _reject(self, request, reason): response = _get_failure_view()(request, reason=reason) log_response( 'Forbidden (%s): %s', reason, request.path, response=response, request=request, logger=logger, ) return response def _get_token(self, request): # ... def _set_token(self, request, response): # ... def process_request(self, request): csrf_token = self._get_token(request) if csrf_token is not None: # Use same token next time. request.META['CSRF_COOKIE'] = csrf_token def process_view(self, request, callback, callback_args, callback_kwargs): if getattr(request, 'csrf_processing_done', False): return None # Wait until request.META["CSRF_COOKIE"] has been manipulated before # bailing out, so that get_token still works if getattr(callback, 'csrf_exempt', False): return None # Assume that anything not defined as 'safe' by RFC7231 needs protection if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'): if getattr(request, '_dont_enforce_csrf_checks', False): # Mechanism to turn off CSRF checks for test suite. # It comes after the creation of CSRF cookies, so that # everything else continues to work exactly the same # (e.g. cookies are sent, etc.), but before any # branches that call reject(). return self._accept(request) # 判断是不是 https 协议，不然不用执行这里 if request.is_secure(): # ... csrf_token = request.META.get('CSRF_COOKIE') if csrf_token is None: # No CSRF cookie. For POST requests, we insist on a CSRF cookie, # and in this way we can avoid all CSRF attacks, including login # CSRF. return self._reject(request, REASON_NO_CSRF_COOKIE) # Check non-cookie token for match. request_csrf_token = "" if request.method == "POST": try: request_csrf_token = request.POST.get('csrfmiddlewaretoken', '') except IOError: # Handle a broken connection before we've completed reading # the POST data. process_view shouldn't raise any # exceptions, so we'll ignore and serve the user a 403 # (assuming they're still listening, which they probably # aren't because of the error). pass if request_csrf_token == "": # Fall back to X-CSRFToken, to make things easier for AJAX, # and possible for PUT/DELETE. request_csrf_token = request.META.get(settings.CSRF_HEADER_NAME, '') request_csrf_token = _sanitize_token(request_csrf_token) if not _compare_salted_tokens(request_csrf_token, csrf_token): return self._reject(request, REASON_BAD_TOKEN) return self._accept(request) def process_response(self, request, response): if not getattr(request, 'csrf_cookie_needs_reset', False): if getattr(response, 'csrf_cookie_set', False): return response if not request.META.get("CSRF_COOKIE_USED", False): return response # Set the CSRF cookie even if it's already set, so we renew # the expiry timer. self._set_token(request, response) response.csrf_cookie_set = True return response这里比较复杂的部分就是 process_view() 方法。process_request() 方法只是从请求头中取出 csrftoken 值或者生成一个 csrftoken 值放到 request.META 属性中去；process_response() 会设置对应的 csrftoken 值到 cookie 或者 session 中去。这里获取 csrftoken 和 设置 csrftoken 调用的正是 _get_token() 和 set_token()方法：class CsrfViewMiddleware(MiddlewareMixin): # ... def _get_token(self, request): if settings.CSRF_USE_SESSIONS: try: return request.session.get(CSRF_SESSION_KEY) except AttributeError: raise ImproperlyConfigured( 'CSRF_USE_SESSIONS is enabled, but request.session is not ' 'set. SessionMiddleware must appear before CsrfViewMiddleware ' 'in MIDDLEWARE%s.' % ('_CLASSES' if settings.MIDDLEWARE is None else '') ) else: try: cookie_token = request.COOKIES[settings.CSRF_COOKIE_NAME] except KeyError: return None csrf_token = _sanitize_token(cookie_token) if csrf_token != cookie_token: # Cookie token needed to be replaced; # the cookie needs to be reset. request.csrf_cookie_needs_reset = True return csrf_token def _set_token(self, request, response): if settings.CSRF_USE_SESSIONS: if request.session.get(CSRF_SESSION_KEY) != request.META['CSRF_COOKIE']: request.session[CSRF_SESSION_KEY] = request.META['CSRF_COOKIE'] else: response.set_cookie( settings.CSRF_COOKIE_NAME, request.META['CSRF_COOKIE'], max_age=settings.CSRF_COOKIE_AGE, domain=settings.CSRF_COOKIE_DOMAIN, path=settings.CSRF_COOKIE_PATH, secure=settings.CSRF_COOKIE_SECURE, httponly=settings.CSRF_COOKIE_HTTPONLY, samesite=settings.CSRF_COOKIE_SAMESITE, ) # Set the Vary header since content varies with the CSRF cookie. patch_vary _headers(response, ('Cookie',)) # ...如果我们没在 settings.py 中设置 CSRF_USE_SESSIONS 值时，在 django/conf/global_settings.py 默认设置为 False，那么我们就是调用前面熟悉的 response.set_cookie() 方法取设置 cookie 中的 key-value 值，也是我们在上面第二张图片所看到的 Set-Cookie 里面的值。我们来看最核心的处理方法：process_view()。它的执行流程如下所列，略有删减，请仔细研读和对照代码：判断视图方法是否有 csrf_exempt 属性。相当于该视图方法添加了 @csrf_exempt 装饰器，这样不用检验 csrf_token 值，直接返回 None，进入下面的中间件执行，直到视图函数去处理 HTTP 请求；对于 GET、HEAD、 OPTIONS、 TRACE 这四种请求不用检查 csrf_token，会直接跳到最后执行 self._accept(request) 方法。但是我们常用的如 POST、PUT 以及 DELETE 等请求会进行特别的处理；来看针对 POST、PUT 以及 DELETE 的特殊处理，要注意两处代码：request_csrf_token 值的获取：对于 POST 请求，我们要从请求参数中获取，这个值正是表单中隐藏的随机 csrf_token，也是我们在第一张图中看到的值，每次请求都会刷新该值；而且对于其它的请求，该值则是从 request.META 中获取；校验 csrf_token 值是否正确。如果是不正确的 csrf_token 值，则会直接返回 403 错误；if not _compare_salted_tokens(request_csrf_token, csrf_token): return self._reject(request, REASON_BAD_TOKEN)可以看到，这里校验的是两个值：一个是我们从 cookie 中获取的，另一个是前端表单中隐藏的那个随机数。现在我们大致心里有个数了，Django 的校验方法竟然是用 cookie 中的值和页面上的随机值进行校验，这两个值都是64位的，你必须同时拿到这两个正确 token 值才能通过 Django 的 csrf 中间件校验。比较原理，2个 token，一个放到 cookie 中，另一个放到表单中，会一直变得那种。接下来就是对这两个 token 进行对比。我们继续追踪 _compare_salted_tokens() 方法，可以在 csrf.py 中找到如下两个方法，它们分别对应着 csrf_token 值的生成和解码：# 源码位置：django/middleware/csrf.py# ...def _salt_cipher_secret(secret): """ Given a secret (assumed to be a string of CSRF_ALLOWED_CHARS), generate a token by adding a salt and using it to encrypt the secret. """ salt = _get_new_csrf_string() chars = CSRF_ALLOWED_CHARS pairs = zip((chars.index(x) for x in secret), (chars.index(x) for x in salt)) cipher = ''.join(chars[(x + y) % len(chars)] for x, y in pairs) return salt + cipherdef _unsalt_cipher_token(token): """ Given a token (assumed to be a string of CSRF_ALLOWED_CHARS, of length CSRF_TOKEN_LENGTH, and that its first half is a salt), use it to decrypt the second half to produce the original secret. """ salt = token[:CSRF_SECRET_LENGTH] token = token[CSRF_SECRET_LENGTH:] chars = CSRF_ALLOWED_CHARS pairs = zip((chars.index(x) for x in token), (chars.index(x) for x in salt)) secret = ''.join(chars[x - y] for x, y in pairs) # Note negative values are ok return secret# ...来看这两个函数，首先是 _salt_cipher_secret() 方法，需要传入一个长度为 32 的 secret，就可以得到一个64位的随机字符。这个 secret 值在使用时也是随机生成的32个字符：# 源码位置：django/middleware/csrf.pydef _get_new_csrf_string(): return get_random_string(CSRF_SECRET_LENGTH, allowed_chars=CSRF_ALLOWED_CHARS)# 源码位置：django/utils/crypto.pydef get_random_string(length=12, allowed_chars='abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'): """ Return a securely generated random string. The default length of 12 with the a-z, A-Z, 0-9 character set returns a 71-bit value. log_2((26+26+10)^12) =~ 71 bits """ if not using_sysrandom: # This is ugly, and a hack, but it makes things better than # the alternative of predictability. This re-seeds the PRNG # using a value that is hard for an attacker to predict, every # time a random string is required. This may change the # properties of the chosen random sequence slightly, but this # is better than absolute predictability. random.seed( hashlib.sha256( ('%s%s%s' % (random.getstate(), time.time(), settings.SECRET_KEY)).encode() ).digest() ) return ''.join(random.choice(allowed_chars) for i in range(length))在 _salt_cipher_secret() 方法中我们可以看到，传入32位的密钥 secret，最后的 csrf_token 的生成是 salt + cipher，前32位是 salt，后32位是加密字符串。解密的过程差不多就是 _salt_cipher_secret() 的逆过程了，最后得到 secret。我们可以在 Django 的 shell 模式下使用下这两个函数：(django-manual) [root@server first_django_app]# python manage.py shellPython 3.8.1 (default, Dec 24 2019, 17:04:00) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linuxType "help", "copyright", "credits" or "license" for more information.(InteractiveConsole)>>> from django.middleware.csrf import _get_new_csrf_token, _unsalt_cipher_token>>> x1 = _get_new_csrf_token()>>> x2 = _get_new_csrf_token()>>> x3 = _get_new_csrf_token()>>> print('x1={}\nx2={}\nx3={}'.format(x1, x2, x3))x1=dvK3CRLiyHJ6Xgt0B6eZ7kUjxXgZ5CKkhl8HbHq8CKR0ZXMOxYnigzDTIZIdk3xZx2=TMazqRDst3BSiyxIAI1XDiFKdbmxu8nKRVvMogERiZi6IG6KNhDSxcgEOPTqU0qFx3=gy998wPOCZJiXHo7HYQtY3dfwaevPHKAs2YXPAeJmWUaA5vV2xdXqvlidLR4XM1T>>> _unsalt_cipher_token(x1)'e0yOJ0P0edi4cRtY62jtjpTKlcCopBXP'>>> _unsalt_cipher_token(x2)'8jvn8zbzZ6RoAiJcnJM544L4LOH3A2d5'>>> _unsalt_cipher_token(x3)'mEZYRez5U7l2NyhYvJxECCidRLNJifrt'>>> 了解了上述这些方法后，现在来思考前面提出的问题：为什么每次刷新表单中的 csrf_token 值会一直变化，而 cookie 中的 csrf_token 值却一直不变呢？首先我们看在页面上生成随机 token 值的代码，也就是将标签 {{ csrf_token }} 转成 64位随机码的地方：# 源码位置： django/template/defaulttags.py@register.tagdef csrf_token(parser, token): return CsrfTokenNode()class CsrfTokenNode(Node): def render(self, context): csrf_token = context.get('csrf_token') if csrf_token: if csrf_token == 'NOTPROVIDED': return format_html("") else: return format_html('<input type="hidden" name="csrfmiddlewaretoken" value="{}">', csrf_token) else: # It's very probable that the token is missing because of # misconfiguration, so we raise a warning if settings.DEBUG: warnings.warn( "A {% csrf_token %} was used in a template, but the context " "did not provide the value. This is usually caused by not " "using RequestContext." ) return ''可以看到 csrf_token 值是从 context 中取出来的，而在 context 中的 csrf_token 值又是由如下代码生成的：# 源码位置：django/template/context_processors.pyfrom django.middleware.csrf import get_token# ...def csrf(request): """ Context processor that provides a CSRF token, or the string 'NOTPROVIDED' if it has not been provided by either a view decorator or the middleware """ def _get_val(): token = get_token(request) if token is None: # In order to be able to provide debugging info in the # case of misconfiguration, we use a sentinel value # instead of returning an empty dict. return 'NOTPROVIDED' else: return token return {'csrf_token': SimpleLazyObject(_get_val)}可以看到，最后 csrf_token 值还是由 csrf.py 文件中的 get_token() 方法生成的。来继续看这个 get_token() 方法的代码：# 源码位置：django/middleware/csrf.pydef get_token(request): """ Return the CSRF token required for a POST form. The token is an alphanumeric value. A new token is created if one is not already set. A side effect of calling this function is to make the csrf_protect decorator and the CsrfViewMiddleware add a CSRF cookie and a 'Vary: Cookie' header to the outgoing response. For this reason, you may need to use this function lazily, as is done by the csrf context processor. """ if "CSRF_COOKIE" not in request.META: csrf_secret = _get_new_csrf_string() request.META["CSRF_COOKIE"] = _salt_cipher_secret(csrf_secret) else: csrf_secret = _unsalt_cipher_token(request.META["CSRF_COOKIE"]) request.META["CSRF_COOKIE_USED"] = True return _salt_cipher_secret(csrf_secret)注意！注意！最关键的地方来了，这个加密的 secret 的值是从哪里来的？正是从请求头中的 cookie 信息中来的，如果没有将生成一个新的密钥，接着把该密钥生成的 token 放到 cookie 中。最后使用 _salt_cipher_secret() 方法生成的 csrf_token 和 cookie 中的 csrf_token 具有相同的密钥。同时拿到了这两个值，就可以进行校验和判断，下面我们在 ``_salt_cipher_secret()方法中加上一个print()` 语句，然后执行下看看是否如我们所说。22可以看到每次生成 token 时加密的秘钥都是一样的。我们从上面生成的 csrf_token 中选一个进行解密，得到的结果和 cookie 中的正是一样的密钥：>>> from django.middleware.csrf import _unsalt_cipher_token# 两个 token 解密是相同的，这才是正确的>>> _unsalt_cipher_token('2Tt8StiU4rZcvCrTb2KqJwTTOTCP0WvJhp7GyTj58RGv97IvJInxyrAN4DKCdt1M')'pGOIQAbleARtOFrMIQNhZ5R4qUiXnHGd'>>> _unsalt_cipher_token('VI68m6xT1JczSsnuJvxqtcr0L0EvCN1DaeKG2wy459TSwXE6hbaxi78U1KMiPkxG')'pGOIQAbleARtOFrMIQNhZ5R4qUiXnHGd'现在大部分代码我们也算清楚了，csrf_token 的校验原理我们也知道了。那么如果想自己生成 csrf_token 并通过 Django 的校验也非常简单，只需要通过那个密钥生成一个 csrf_token 或者直接输入使用密钥都可以通过校验。我们首先使用密钥在 shell 模式下随机生成一个 csrf_token 值：>>> from django.middleware.csrf import _salt_cipher_secret>>> _salt_cipher_secret('pGOIQAbleARtOFrMIQNhZ5R4qUiXnHGd')'ObaC9DEZfn4seXbOhgBCph2Y5PMjm0Eo3HOaP3FajNLLSssqPWeJecJSlzU6zxar接下来在看我的演示，第一此我随机改动 csrf_token 的字符，这样校验肯定通不过；接下来我是用自己生成的 token 值以及直接填写密钥再去提交都能通过校验。为了方便演示结果，我们在 csrf.py 的 process_view() 函数中添加几个 print() 方法，方便我们理解执行的过程。23

struts2的校验相关搜索

s line safari浏览器 samba SAMP samplerate sandbox sanitize saper sas sass save smarty模板 smil smtp snapshot snd snmptrap soap soapclient soap协议

查看更多慕课网实用课程