Python 模块
一个Python Module(模块)，是一个文件，包含了Python对象定义和Python语句（definitions and statements）。文件名就是模块名加上后缀.py，在模块内部，模块名存储在全局变量__name__中，是一个string，可以直接在module中通过__name__引用到module name。
module是为了重复使用一些对象，比如类，函数，而将这些对象定义放在一个.py文件中，或是将一个较大的工程裁缝为多个.py文件而易于维护，每一个.py文件都是一个module。
1，模块的定义和引入(import)
如下一个fibo.py文件
1 print ("__name__ :", __name__) 2 def fib(n): 3 a, b = 0, 1 4 result = [] 5 print ("in fib():", __name__) 6 while (b<n): 7 result.append(b) 8 a, b = b, a+b 9 print(result)
这个fibo.py就是一个module，它有一个函数定义fib()，和一个语句(statement)，第一行的print语句，我们在当前文件目录运行Python Interpreter就可以去引入这个模块，并执行模块中定义的fib()函数。
>>> import fibo ('__name__ :', 'fibo') #print语句执行 >>> fibo.fib(10) ('in fib() :', 'fibo') #fib()函数执行 [1, 1, 2, 3, 5, 8]
可以看到，在import的时候，这个module的语句(statements)执行了，所定义的函数并未执行，在通过module名引用module中的函数定义时，函数才被执行
同样可以在一个script file中引入module，我们在fibo.py所在的目录创建另一个文件calculat.py
1 from fibo import fib 2 for n in range(10, 50, 5): 3 fib(n)
然后用Python解释器运行calcute.py得到结果。
这里有两种import 语句，
一种是import module_name1 [as name1], module_name2 [as name2]
一种是from module_name import item1 [as name1], item2 [as name2]
2, module的加载
每个module都包含对象定义和一些语句(statements)，这些语句应该是意图要来初始化这个module的，这些语句会在这个module第一次被import的时候执行（多次import只会执行一次,不管是以上两种import的语句中那一种），当这个module被作为一个script来运行的时候也会被执行。
每个module都有自己的private symbol table，当使用第一种import语句import一个module的时候，引入者的local symbol table就加入了这个module，其名字如果没有使用as的话就是被引入的模块名本身。使用第二种import语句这会在引入者的local symbol table中加入具体引用的item，其名称若没使用as则就为item的名称。
3，module搜索路径
当遇到一个名为xiaoyu的module需要import的时候，Python Interpreter首先搜寻built-in module中有没有叫这个名的，若是没有，则Interpreter会从一系列的目录中去搜寻这个module(也就是这个.py文件)，这些目录值存储在sys.path中，而sys.path又是用这些值来初始化的：
- 当前目录，即input script所在的目录
- 环境变量PYTHONPATH中存储的值(PYTHONPATH的语法和PATH一样)
- Python包的安装目录，比如我的服务器上django就安装在 /usr/local/lib/python2.7/dist-packages/中，sys.path含有这个目录
Python有一个标准库，其中定义了一系列的module，这些module中的一部分是直接集成在Interpreter中的，这些built-in module主要提供了很重要的但是Python语言又没有提供的功能，比如跟system call有关的sys module就集成在所有平台的Python Interpreter中，在Interpreter中集成哪些module是可以配置的，并且随平台不同而有差别。
在启动Interpreter，sys.path被初始化后，我们可以对它进行修改
>>> import sys>>> sys.path.append('/root/home/project/code/python') |
4， 把module作为script来执行
前面我们已经提到了关于module中语句的执行。这里要补充一点东西，通常一个script file指的是调用Python Interpreter时作为参数传递给Interpreter的文件，当然所有的.py文件都是一个module，这样的一个script或是module，其__name__会被Interpreter自动设置为"__main__"。以下是一个测试:
1 print ("__name__ :", __name__) 2 def fib(n): 3 a, b = 0, 1 4 result = [] 5 print ("in fib() :", __name__) 6 while (b<n): 7 result.append(b) 8 a, b = b, a+b 9 print(result) 10 11 if __name__ == "__main__": 12 import sys
13 fib(int(sys.argv[1]))
用Python Interpreter直接调用这个script
oot@AY1212240253255e84714:/home/project/code/python# python fibo.py 22('__name__ :', '__main__')('in fib() :', '__main__')[1, 1, 2, 3, 5, 8, 13, 21] |
可以看到依然module的语句都会被执行，只是__name__的值一开始就变为了"__main__"，给一个模块加上
if __name == "__main__":
常常是为了测试这个模块，因为这个语句块只有当module被作为script直接传给Interpreter的时候才会被执行。
上面例子中的12行import sys可以看出，Python并没有规定import语句必须写在module的最前面，只是习惯性的我们约定都写在最前面。
5. 内置dir()函数（built-in dir() function）
dir()函数可以用来查看一个module所定义的所有names，试验
>>> dir()['__builtins__', '__doc__', '__name__', '__package__']>>> import sys, fibo as fibo_local('__name__ :', 'fibo')>>> dir()['__builtins__', '__doc__', '__name__', '__package__', 'fibo_local', 'sys']>>> dir(fibo)Traceback (most recent call last): File "<stdin>", line 1, in <module>NameError: name 'fibo' is not defined>>> dir(fibo_local)['__builtins__', '__doc__', '__file__', '__name__', '__package__', 'fib'] |
可以看到在import了fibo和sys后，并且fibo是用别名fibo_local来引入的，在引入者module中就定义了sys和fibo_local，可以看到dir(fibo)是抛了NameError异常的，fibo并没有被定义，定义的是fibo_local，这也可以看出import语句对local symbol table是怎样影响的。
6, 模块包(package)
包(package)可以理解为是组织起来的module的一个层次结构，也就是package是一个directory，它包含sub-package或者是module，而module是.py文件，要让Python Interpreter把一个目录作为package，则该目录下必须有__init__.py文件，__init__.py可以为空，当然也可以有对象定义和语句，用来做初始化工作，__init__.py还有个作用就是设置__all__变量。
package本身就可以来作为一个module使用，只是它所包含的sub-module或module可以通过package name用package.module的名称形式去引用，这更有利于组织一系列相关的module，避免module间定义的名称的混乱。
package在实际工程中非常常用，__init__.py也常常不会为空，而会有对象定义和初始化代码来让这个包，也就是这个module，包含其该有的item定义。以后我们会对package做更多了解。
一些docs.python.org上的参考材料
modules http://docs.python.org/3.3/tutorial/modules.html
import statement http://docs.python.org/3.3/reference/simple_stmts.html#the-import-statement
Python execution model http://docs.python.org/3/reference/executionmodel.html
Python import system http://docs.python.org/3/reference/import.html
CSRF 攻击
在 Django 的表单中硬性添加 {% csrf_token %} 标记如下，否则在提交表单的时候会出错，目的就是为了防止 CSRF 攻击：
|
1
2
3
4
5
6
7
|
<form action="/summit_question" method="post"> 。。。。。。</form><!-- error -->Forbidden (403)CSRF verification failed. Request aborted. |
CSRF 全称是 Cross-site request forgery，即跨站点请求伪造。当恶意的网站被访问时，会产生伪造的请求发送给服务器，伪造请求中可能存留了用户的 cookie，服务器也无法区分请求真伪，因此数据被提交甚至修改，给用户带来损失。
小明如果遭受 CSRF 攻击严重的有如下现象，情景假设：
小明早上起来登录了 shopping.com 购物网站；
在登录后同时在新的标签中打开了一个恶意（malicious）网站，并点击了里面的一个按钮或者图片；
回到 shopping.com 的时候发现，他账户里的钱少了 ￥1000。
上面的只是情景假设，一般的购物网站不会这样单纯。试着看看里面它是如何工作的：
小明成功登录了 shopping.com 网站，他的浏览器保存了浏览器产生的一个 cookie，注意此 cookie 中保存了某些登录信息或者授权信息。同时我们假设：shopping.com 服务器向账户 「123456」转账 ￥1000 的接口是：
|
1
2
3
4
5
6
7
8
|
产生的 HTTP 请求可能是：...Cookie:XXXXXXXXXX... |
未名攻击者特地写了个带图片的链接，可以是下面的形式：
|
1
|
<a href="daoluan.net"><img height="185" width="185" alt="" src="http://shopping.cm/Transfer.html?toAccount=123456&money=1000"></a> |
小明傻乎乎的点击打开，于是浏览器尝试装载图片的时候，同时提交了小明的 cookie。服务器收到此请求，验证 cookie 正确后，于是修改了数据，即给账户「123456」转账 ￥1000.没错，在装载图片过程中会产生上面形式的 HTTP 请求。
电商 shopping.com 不会简单的发送 HTTP GET 请求转账，HTTP GET 本身基因就决定他必须把参数暴露在链接中。那采用安全点的 POST 如何？编写一个 method 为 POST 的表单就达到目标。以上的情况严重点，CSRF 稍微好一点的情景是通由小明在某个站点上的登录，提交一个评论。
有两种方法可以防止 CSRF：
- 检测 HTTP header 中的 referer 字段。服务器可以查看 referer 是否为自己的站点，如果不是，则拒绝服务。
- 在 form 表单中嵌入隐藏域（tpye="hidden"），当表单被提交的时候检测隐藏域的值。隐藏域的值可以是用 md5 hash 产生的值，表单的一些信息，或是服务器上的一个密码。另一个可行的方案是服务器给每一个表单产生一次性的串。Django 就是用这种方法。表单提交后，服务器检测一下是不是有效的值。
- 两者的结合。
第一种方法很容易攻破，修改 HTTP header 中的 referer 字段就好了，另外据说用户可以设置浏览器忽略 referer；第二种方法服务器数据库方面会添加点压力，而且要设定隐藏域值的过期时间。综合来看，第二种方法更可取。
CSRF 攻击通常会调用 JavaScript 自动提交跨站表单，然而，不用 JavaScript 一个恶意的站点也能让用户向另一个站点提交表单，因为表单是可以隐藏的，并且按钮可以伪装成一个按钮。 说白了，HTTP 是无状态协议，对于前一个请求和后一个请求，web 服务器无法区分是否来自同一个浏览器（用户）。现在还有很多网站是这么做的：在服务器中使用 session 保存会话，结合着客户端浏览器的 cookie，简单来说客户端浏览器保存的 cookie 和 服务器中的 session 存在一一对应的关系，于是只要有第三方获取了客户端浏览器保存的 cookie 值，接下来的攻击就好办了。
最近在威信公众平台上做了一个学校图书馆应用，可以搜书和查询用户在图书馆的借阅情况，和学校沟通开放接口这个应该是不可能的了，这个其实就是类似 CSRF 的攻击。如果华师的同学，可以关注 betalife 这个公众帐号。
参考：http://www.squarefree.com/securitytips/web-developers.html#CSRF
捣乱 2013-07-23
http://daoluan.net/blog