| Blog信息 |
|
blog名称:
日志总数:1304
评论数量:2242
留言数量:5
访问次数:7645791
建立时间:2006年5月29日 |
| |
|
 [Django]fastCGI方式跑Django
软件技术
lhwork 发表于 2007/1/15 17:34:30 |
| 原本想找个支持mod_python的空间来玩玩，但是要么太贵要么速度太慢，终究还是选择了dreamhost，在他上面买了支持python的空间，打算好好玩玩python这个东东，之前看了看上面的环境：
<a href="mailto:hackgou@runts:~$">hackgou@runts:~$</a> whereis python
python: /usr/bin/python /usr/bin/python2.3 /usr/bin/python2.2-popy-config \
/usr/bin/python2.2 /usr/bin/python2.4 /etc/python2.3 /etc\
/p |
|
|
[Django]Django 学习笔记 － i18n 支持 
软件技术
lhwork 发表于 2007/1/15 16:37:46 |
最近再用 Django 做东西，顺便写点笔记做下记录。
今天折腾这个 Django 的 i18n 支持着实费了点功夫，主要是一开始没理解 Python 做 i18n 的原理导致。废话不多说了，使用 Django 的 i18n 支持还是相当的方便的。Django 的官方文档上讲的很详细了，但是篇幅过长，我也是硬着头皮看了几遍才搞明白，下面我就简单介绍一下最快捷的方法。
首先，从配置入手，settings.py 里面有一个 LANGUAGE_CODE属性，这里设置了网站默认的语言。由于settings.py里面的属性支持重写，所以从官方文档上可以得知，默认情况下已经启用i18n支持了，我们需要加入一些middleware来支持动态切换语言。
MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.mid |
|
|
[Django]Django 学习笔记 － Apache2 + FastCGI
软件技术
lhwork 发表于 2007/1/15 16:32:34 |
昨天开始学习Django站点的生产服务器（Production Server），尝试了一下lighttpd和Apache2，最后决定采用Apache2来搭建整个环境（其实lighttpd更为方便一些）。
虽然Apache2 + mod_python就可以跑Django站点服务，但是听说FastCGI有更优异的性能。
FastCGI applications are fast because they're persistent. There is no per-request startup and initialization overhead. This makes possible the development of applications which would otherwise be impractical within the CGI paradigm (e.g. a huge Perl script, or an application which requires a connection to one or |
|
|
[Django]Decorator在SharePlat中的使用
软件技术
lhwork 发表于 2007/1/15 10:55:23 |
在最近的 SharePlat 的项目中，我想使用一些 decorator 来进行处理，有些 decorator 需要一些参数，因此上生成的 decorator 就有一些复杂，比如：
def template(templatename):
"""
render the func's result into a template
"""
def _render(func):
def _f(*args, **kwargs):
re |
|
|
[Django]Easy Captcha的再思考
软件技术
lhwork 发表于 2007/1/15 10:55:01 |
头太晕在我的blog中留言说我的实现方法无法解决第一次手工输入，以后一直使用这个正确的值来攻击的问题，我想一想的确如此。看来完全依赖客户端是不够的，还是要在后台做一些工作。为了让后台的工作尽量少，我不想单独建表来象session一样的处理。我也不想去产生一个id与word进行对应，因为生成id是一个问题，为了保证不重复，要通过循环来实现，感觉不好。于是我想不如将key的生成时间也写在key中，这样在后台我只要判断是否超时，就可以让这个key失败。但这也只是解决了key的长期有效的问题，无法解决在短时间内攻击的问题。那么我想可以利用cache的机制，一旦key中的word验证有效，并且没有失效，那么先在cache中查找是否存在，如果不存在则说明没有验证过，然后在cache中设置一个word值既可。这样，下次再次校验相同的word时，因为cache中已经有了这个值，所以验证失效。我想这样应该可以解决问题。改动的代码如下：
#django binding
from |
|
|
[Django]Easy Captcha的实现
软件技术
lhwork 发表于 2007/1/15 10:53:57 |
| 前面的blog中我已经开始研究 pycaptcha 的实现机理，就是想实现一个简单的 captcha 的机制。那么在 session 学习中，我们也了解了 session 的机制与 pycaptcha 的机制差不多，但是我感觉很麻烦。
那么如何才简单呢？考查现有的 pycaptcha 实现，它是将客户端的识别信息与生成图片的文本进行对应，即一个id对应一系列的solution(文本串)，前端只看到id，然后通过提交将id和看到的图片中的文本一起传到后台，然后后台处理需要根据id得到对应的solution，再比较solution与上传的文本是否一致。如果一致则成功，否则失败。那么需要在后台保存id与solution的关系，这也很麻烦。因此我想如果前端保存的id包含了生成的文本，那么只要在后台比较这个文本与用户输入的文本是否一致就行了。那么这个id需要足够安全才好。同时可以根据这个id生成相应的图片。因此从处理上可以这样：
首先生成模版，在模版中生成一个key，并将这个key保存到一个hidden字段中。然后再生成一个图片的链接，将key作为一个索引。 |
|
|