小编mr_*_*r_c的帖子

作为cookie的初学者,CSRF和Django(使用1.4),从我可以看出它是如何工作的,请纠正我出错的地方......

以下适用于MIDDLEWARE_CLASSES元组中包含django.middleware.csrf.CsrfViewMiddleware的情况.

如果POST表单包含csrf_token标记,并且相关视图传递RequestContext给模板,请求页面意味着Django包含一个包含字母数字字符串的隐藏表单字段.Django还会向浏览器返回一个名称设置为的cookie,csrftoken并将值设置为相同的字母数字字符串.

收到表单提交时,Django会检查隐藏表单字段中的字母数字字符串值是否匹配以及从浏览器收到的csrftoken cookie.如果它们不匹配则发出403响应.

CSRF攻击可能以包含iframe的恶意网站的形式出现.iframe包含POST表单和一些JavaScript.表单的action属性指向我的Django站点.该表单旨在在我的站点上做一些讨厌的事情,并且在加载iframe时JS提交表单.

浏览器将csrftoken在表单提交的标题中包含cookie.但是,表单不会包含带有匹配的字母数字字符串的隐藏字段,因此返回403并且攻击失败.如果iframe JS试图访问cookie,以便创建正确的hiddden表单字段,浏览器将阻止它这样做.

它是否正确？

在Crockford的JavaScript:The Good Parts的第90页,他的代码有以下内容:

String.method('entityify', function(){

  var character = {
    '<': '&lt;',
    '>': '&gt;',
    '&': '&amp;',
    '"': '&quot;'
  };

  return function(){
    return this.replace(/[<>&"]/g, function(c){
      return character[c];
    });
  };
}());

console.log("<&>".entityify());

是否有充分的理由关闭并立即调用外部函数？以下似乎也适用:

String.method('entityify', function(){

  var character = {
    '<': '&lt;',
    '>': '&gt;',
    '&': '&amp;',
    '"': '&quot;'
  };

  return this.replace(/[<>&"]/g, function(c){
    return character[c];
  });
});

根据关于异常的成语和反成语的Python文档:"你应该尝试尽可能少地使用代码中的子句 - 你使用的那些通常是在应该总是成功的调用中,或者在主要功能中抓住所有." 分段考虑这句话......

"你应该尝试尽可能少地使用代码中的除了子句"

对于像我这样的新手来说有点令人困惑,我认为在Python中使用EAFP样式 - 很多try和except语句是很好的做法.或者我错过了这一点？

"你使用的那些通常是在应该总是成功的电话里面"

我不明白这里的意思.

"或者是主要功能的全能."

因此,任何抛出异常的代码都是好的风格,只是简单地将它传递给调用堆栈,直到它达到你真正通用的异常处理的顶层为止？

我正在编写一个继承自ListView的视图,并试图将视图限制为登录用户.

https://docs.djangoproject.com/en/dev/topics/class-based-views/#decorating-in-urlconf说在URLconf中使用login_required进行装饰"在每个实例的基础上应用装饰器.如果你想要的话要装饰的每个视图实例,你需要采取不同的方法" - 这种方法是在视图代码中装饰调度方法.

我以为我知道一个类和一个实例之间的区别,但这句话对我来说没有任何意义.有人可以澄清吗？除了在URLconf中设置装饰器而不是在类定义中,这两种方法之间有什么区别？

该链接上面的段落似乎回答了这样一个问题:"由于基于类的视图不是函数,因此根据您是使用as_view还是创建子类,装饰它们的工作方式会有所不同."

真？？我似乎能够使用我的子类ListView的URLconf方法.

作为一个实验,我尝试捕获失败的断言.

try: assert 1==2
except Exception as e: print e

为什么没有显示？