这还是比较值得推荐的。。。(备注:加载的时候可能有点慢。如果发现加载失败,请重新刷新页面一次)
Submitted by gouki on 2009, January 4, 9:28 AM
这还是比较值得推荐的。。。(备注:加载的时候可能有点慢。如果发现加载失败,请重新刷新页面一次)
Submitted by gouki on 2009, January 2, 12:47 AM
QEEPHP终于发布了,没有看到廖羽雷吃笔记本,也是一种遗憾。
要知道QeePHP可是让人等了整整一年,当年论坛上就有人说:宁可相信世上有鬼也不相信老廖的嘴。可见让人有多失望
不过,在昨天凌晨的时候,QeePHP还是提供了下载,不过下载完了之后还没有时间仔细观摩。
初步看了一下,目录结构与ZF相类似,自动加载类库也使用了spl_auto_load,因为使用了这个函数,造成的后果是,文件名全部是小写了。呵呵(不知道原因的可以去查看这个函数)
其他还没有仔细看。
可以先看官方:http://qeephp.com
Submitted by gouki on 2008, December 28, 10:15 PM
一直以来,IBM developworks都是我比较关注的网站,它上面有很多内容是IBM公司内部人员所写,也有一部分内容是业界领先人士根据自身经验写出的教程,因此,它一直是我的订阅对象之一。本文就是其中一篇比较旧的文章,最初发表于2007年3月15日,但是从今天的眼光来看,它还是有一定的学习价值,所以我贴出来了。
简介如下:(原文我就不贴了,大家可以点其中的链接我自己也会点过去看的)
现在,Web 站点已经成了业务的重要部分,而用来创建和部署 Web 站点的工具也变得更加灵活和容易使用。但是,复杂 Web 应用程序的开发并不轻松,它们需要的不只是标准的交互和更新方法(比如 blog)。组织中的每个应用程序常常还需要进行定制。
开放源码社区提供了各种工具,结合使用这些工具可以为复杂的 Web 应用程序创建一个有用的开发和生产环境。这个系列文章来自 IBM Internet Technology Group 团队,他们将展示如何把开放源码软件作为基础,并提供一种方法和一些改进来帮助简化 Web 站点的开发过程。尽管定制仍然是有必要的,但是这个系列讲解了如何使用开放源码工具和技术快速建立和运行复杂的 Web 站点。
在这个系列中,Internet Technology Group 团队通过一个虚构的组织,International Business Council(IBC),来展示如何更有效地尽可能地扩展 Web 站点的功能,这些功能包括文档存储、讨论组、专门的工作组、研讨会日程安排、日程议题描述、会话过期和其他任务。他们举例说明了创建这个 Web 站点需要用到下列开放源码工具:
Internet Technology Group 团队会首先介绍业务场景以及选择开源工具的决定因素,他们还通过描述一个灵活的开发方法来讲解了应用程序的设计流程。这个流程可以用来设计 Web 站点或者应用程序的用户体验。接着,他们会一步一步地指导如何安装和使用前面所提到的开发工具套件。这些步骤包括:
沿着这条道路,Internet Technology Group 团队同其他可选方案进行了对比,并讨论了如何通过集成其它软件组件来尽可能地增强这些工具。
现在就链接到 项目实现:
Submitted by gouki on 2008, December 28, 9:00 PM
文章的内容写的不错,所以转载一下。
原文:http://xinsync.xju.edu.cn/index.php/archives/2946
内容如下:
SVN的机制确实是很多人现在所考虑的,一来这样保证了代码的同步,二来也不需要担心开发版和上线版的区别,更重要的是,每次的update你肯定不会有错。
文件上传其实才是一个大头,当你的服务器过多的时候,你如何保证每一台服务器的上传内容同步?如果你同步了,那么这么多的冗余文件是否是一个浪费?如果你不同步,而采用同一个NFS服务器来存储,那么就象文中说的如果NFS宕机了怎么办?给NFS也来一个负载均衡?
总之,当服务器越来越多的时候,你考虑的就不仅仅是代码的问题,而是架构的问题
Submitted by gouki on 2008, December 19, 8:17 PM
原文来自:http://www.phpv.net/html/1653.html 内容如下: 一般的网站都会开放rar附件上传,并可能会保留原来文件名称,这从而可能导致一个很严重的问题,xxx.php.rar文件会被Apache当作php文件来执行, 造成极大的安全隐患 . 如何测试? 将你的某个php程序文件后缀名修改成 xxx.php.rar , 这时测试一下, 还是按照PHP文件解析执行,Apache并不会认为这是一个rar文件, 这是为什么呢? 原 来,每遇到一种后双重后缀名(如xxx.php.rar)的文件,Apache都会去conf/mime.types 文件中检查最后一个后缀, 如果最后一个后缀并没有在mime.types文件中定义, 则使用前一个后缀来解释 , 因为在默认情况下,rar并未在mime.types中定义, 故Apache会使用php后缀来解释文件, 这就是漏洞的原因所在. 由此类推,如果使用xxx.jsp.ppp.rar 则会认为是jsp文件, 如果修改成xxx.shtml.rar ,则会识别成shtml文件. a.php.c.d.e.rar 也是会被当成PHP文件解释的! 那么针对网络管理员,如何杜绝这个隐患 ? 针对WEB管理员及WEB程序开发者,如何更安全? 早期版本的phpcms 2007, discuz, ecshop都存在这个漏洞, 或许你的网站被挂马,就是因此引起. 上面的文章是转的,我测试了一下,还真这样,不过修改mime.types是没有用的. 需要在http.conf中加入下面这些内容 AddType application/rar .rar 这样就不会出问题了,测试过了,加我上面这些是没有问题的。
作者是:扶凯
注意,经测试,本情况发生在少量配置有问题的服务器上.一般正式版apache无此问题.
想想,不知道有多少网站存在这个问题?
1.修改mime.types文件,在最后面加一条:
application/rar rar
然后重新启动Apache,即可.
1.只允许上传指定后缀名的文件,当然,要禁止掉rar格式文件上传.(但这条往往行不通,一般的网站都需要上传rar文件)
2.对上传后的文件进行强制重命名, 强制使用最后一个扩展名,如原始文件名为xxx.php.rar ,上传后强制重命名为 20080912.rar即可避免这个隐患.
AddType application/x-compressed .rar
AddType application/x-rar .rar
AddType application/x-rar-compressed .rar
AddType application/x-rar-compressed; application/x-compressed .rar
AddType compressed/rar; application/x-rar-compressed .rar
听闻有这样的漏洞,不管怎么样,都放上来,与大家一起分享一下,同时也请你自己检测一下自己的apache,如果你用的虚拟主机有这样的漏洞,那么也尽早通知他们一声,与人方便与己方便。
我自己没有测试过,所以不知道是否存在这个漏洞。