|
ySJ
|
2.0/chapter17/#241 |
2010-04-26 15:18:45
|
这个中间件并 <emphasis>不</emphasis> 验证 <literal>HTTP_X_FORWARDED_FOR</literal> 的合法性。
|
|
|
ySJ
|
2.0/chapter17/#244 |
2010-04-26 15:19:49
|
这是任何人都能够伪造 <literal>HTTP_X_FORWARDED_FOR</literal> 值，而 <literal>REMOTE_ADDR</literal> 又是依据 <literal>HTTP_X_FORWARDED_FOR</literal> 来设置，这就意味着任何人都能够伪造IP地址。
|
|
|
ySJ
|
2.0/chapter17/#246 |
2010-04-26 15:20:31
|
只有当能够绝对信任 <literal>HTTP_X_FORWARDED_FOR</literal> 值的时候才能够使用这个中间件。
|
|
|
ySJ
|
2.0/chapter17/#253 |
2010-04-26 15:20:47
|
这个中间件激活会话支持功能。
|
|
|
ySJ
|
2.0/chapter17/#262 |
2010-04-26 15:21:15
|
已在第15章中详细讨论。
|
|
|
ySJ
|
2.0/chapter17/#277 |
2010-04-26 15:22:37
|
关于数据库事务处理的更多信息，请参见附录B。
|
|
|
ySJ
|
2.0/chapter17/#282 |
2010-04-26 15:24:28
|
在下一章<reference name="next chapter" refuri="../chapter18/">next chapter</reference>，我们将讨论如何集成数据库模式等遗留系统，比如你从20世纪八十年代继承下来的数据库模式。
|
|
|
ySJ
|
2.0/chapter18/#17 |
2010-04-26 15:29:43
|
<literal>inspectdb</literal>工具自省你配置文件指向的数据库，针对每一个表生成一个Django模型，然后将这些Python模型的代码显示在系统的标准输出里面。
|
|
|
ySJ
|
2.0/chapter18/#19 |
2010-04-26 15:30:06
|
下面是一个从头开始的针对一个典型的遗留数据库的整合过程。
|
|
|
ySJ
|
2.0/chapter18/#20 |
2010-04-26 15:34:27
|
两个前提条件是安装了Django和一个传统数据库。
|
|
|
ySJ
|
2.0/chapter18/#26 |
2010-04-26 15:36:09
|
具体的说，要提供 <literal>DATABASE_NAME</literal> , <literal>DATABASE_ENGINE</literal> , <literal>DATABASE_USER</literal> , <literal>DATABASE_PASSWORD</literal> , <literal>DATABASE_HOST</literal> , 和 <literal>DATABASE_PORT</literal> 这些配置信息.。
|
|
|
ySJ
|
2.0/chapter18/#30 |
2010-04-26 15:36:42
|
通过运行 <literal>python mysite/manage.py startapp myapp</literal> (这里 <literal>myapp</literal> 是你的应用的名字)创建一个Django应用。
|
|
|
ySJ
|
2.0/chapter18/#31 |
2010-04-26 15:36:55
|
这里我们使用<literal>myapp</literal> 做为应用名。
|
|
|
ySJ
|
2.0/chapter18/#33 |
2010-04-26 15:37:59
|
运行命令 <literal>python mysite/manage.py inspectdb</literal>。这将检查<literal>DATABASE_NAME</literal> 数据库中所有的表并打印出为每张表生成的模型类。
|
|
|
ySJ
|
2.0/chapter18/#34 |
2010-04-26 15:39:37
|
看一看输出结果以了解inspectdb能做些什么。
|
|
|
ySJ
|
2.0/chapter18/#39 |
2010-04-26 15:40:50
|
编辑 <literal>mysite/myapp/models.py</literal> 文件以清理生成的 models 并且做一些必要的自定义。
|
|
|
ySJ
|
2.0/chapter18/#40 |
2010-04-26 15:42:27
|
针对这个，下一个节有些好的建议。
|
|
|
ySJ
|
2.0/chapter18/#47 |
2010-04-26 15:44:13
|
数据库的每一个表都会被转化为一个model类 (也就是说，数据库的表和model 类之间是一对一的映射)。
|
|
|
ySJ
|
2.0/chapter18/#51 |
2010-04-26 15:45:36
|
但是，请注意，如果某个model没有主键的话，那么Django会自动为其增加一个id主键字段。
|
|
|
ySJ
|
2.0/chapter18/#52 |
2010-04-26 15:46:49
|
这样一来，你也许希望移除这样的代码行。
|
|
|
ySJ
|
2.0/chapter18/#57 |
2010-04-26 15:50:23
|
每一个字段类型，如CharField、DateField， 是通过查找数据库列类型如VARCHAR,DATE来确定的。如果inspectdb无法把某个数据库字段映射到model字段上，它会使用TextField字段进行代替，并且会在所生成model字段后面加入Python注释“该字段类型是猜的”。
|
|
|
ySJ
|
2.0/chapter18/#58 |
2010-04-26 15:51:52
|
对这要当心，如果必要的话，更改字段类型。
|
|
|
ySJ
|
2.0/chapter18/#60 |
2010-04-26 15:52:14
|
如果你的数据库中的某个字段在Django中找不到合适的对应物，你可以放心的略过它。
|
|
|
ySJ
|
2.0/chapter18/#61 |
2010-04-26 15:52:38
|
Django模型层不要求必须导入你数据库表中的每个列。
|
|
|
ySJ
|
2.0/chapter18/#63 |
2010-04-26 15:53:58
|
如果数据库中某个列的名字是Python的保留字（比如pass、class或者for等），inspectdb会在每个属性名后附加上_field，并将db_column属性设置为真实的字段名（也就是pass,class或者for等）。
|
|
|
ySJ
|
2.0/chapter18/#71 |
2010-04-26 15:56:32
|
例如，model Book拥有一个针对于model Author的外键，那么后者应该先于前者被定义。如果你想创建一个指向尚未定义的model的关系，那么可以使用包含model名的字符串，而不是model对象本身。
|
|
|
ySJ
|
2.0/chapter18/#78 |
2010-04-26 15:58:25
|
至于其他数据库，外键字段将在假定其为INT列的情况下被自动生成为IntegerField。
|
|
|
ySJ
|
2.0/chapter18/#88 |
2010-04-26 16:00:46
|
您可以覆盖Diango默认的基于数据库的模式，您还可以使用默认的系统与其他系统进行交互。
|
|
|
ySJ
|
2.0/chapter18/#93 |
2010-04-26 16:01:22
|
当某个人调用 <literal>django.contrib.auth.authenticate()</literal> (如14章中所述)时，Django会尝试对其认证后台进行遍历认证。
|
|
|
ySJ
|
2.0/chapter18/#96 |
2010-04-26 16:01:51
|
认证后台列表在AUTHENTICATION_BACKENDS设置中进行指定。
|
|
|
ySJ
|
2.0/chapter18/#97 |
2010-04-26 16:02:23
|
它应该是指向知道如何认证的Python类的Python路径的名字数组。
|
|
|
ySJ
|
2.0/chapter18/#98 |
2010-04-26 16:02:50
|
这些类可以在你Python路径的任何位置。
|
|
|
ySJ
|
2.0/chapter18/#105 |
2010-04-26 16:04:35
|
AUTHENTICATION_BACKENDS的顺序很重要，如果用户名和密码在多个后台中都是有效的，那么Django将会在第一个正确匹配后停止进一步的处理。
|
|
|
ySJ
|
2.0/chapter18/#107 |
2010-04-26 16:16:20
|
编写认证后台
|
|
|
ySJ
|
2.0/chapter18/#118 |
2010-04-26 16:19:42
|
但是有时候它也可以认证某个短语，例如：
|
|
|
ySJ
|
2.0/chapter18/#122 |
2010-04-26 16:20:20
|
如果它们不合法，就返回<literal>None</literal> |
|
|
ySJ
|
2.0/chapter18/#122 |
2010-04-26 16:23:59
|
如果它们不合法，就返回<literal>None</literal>。
|
|
|
ySJ
|
2.0/chapter18/#124 |
2010-04-26 16:24:20
|
如14章中所述，Django管理系统紧密连接于其自己后台数据库的 <literal>User</literal> 对象。
|
|
|
ySJ
|
2.0/chapter18/#131 |
2010-04-26 16:30:33
|
更多认证模块的后台, 参考Django文档。
|
|
|
ySJ
|
2.0/chapter18/#136 |
2010-04-26 16:33:35
|
最简单直接的办法就是利用Apaches配置文件httpd.conf，将不同的URL类型分发至不同的技术。
|
|
|
ySJ
|
2.0/chapter18/#137 |
2010-04-26 16:34:45
|
（请注意，第12章包含了在Apache/mod_python上配置Django的相关内容，因此在尝试本章集成之前花些时间去仔细阅读第20章或许是值得的。)
|
|
|
ySJ
|
2.0/chapter18/#137 |
2010-04-26 16:34:54
|
（请注意，第12章包含了在Apache/mod_python上配置Django的相关内容，因此在尝试本章集成之前花些时间去仔细阅读第12章或许是值得的。)
|
|
|
ySJ
|
2.0/chapter18/#140 |
2010-04-26 16:35:37
|
在第12章中解释的缺省部署方案假定您需要Django去驱动某个特定域上的每一个页面。
|
|
|
ySJ
|
2.0/chapter18/#150 |
2010-04-26 16:36:57
|
有了这样的设置，只有那些以/admin/开头的URL地址才会触发Django去进行处理。
|
|
|
ySJ
|
2.0/chapter18/#151 |
2010-04-26 16:37:14
|
其他页面会使用已存在的设置。
|
|
|
ySJ
|
2.0/chapter18/#158 |
2010-04-26 16:38:09
|
如果你的母语是英语, 你可能就不会注意到许多Django admin网站中最酷的特性功能。
|
|
|
ySJ
|
2.0/chapter18/#161 |
2010-04-26 16:38:32
|
<reference name="next chapter" refuri="../chapter19/"> 下一章</reference> 介绍如何使用这个框架来提供本地化的Django网站。
|
|
|
ySJ
|
2.0/chapter19/#6 |
2010-04-26 16:55:21
|
鉴于Django社区逐渐变的多样性，<emphasis>国际化</emphasis>和<emphasis>本地化</emphasis>逐渐变得很重要。
|
|
|
ySJ
|
2.0/chapter19/#17 |
2010-04-26 16:59:44
|
Django是带着50个不同的本地化文件发行的。
|
|
|
ySJ
|
2.0/chapter19/#22 |
2010-04-26 17:02:42
|
您只需要添加少量的挂接代码到您的Python代码和模板中。
|
|
