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