4 使用他人CGI脚本时的注意事项
关于CGI,可以从很多地方获得信息——从Internet上,从学校图书馆中,从像本书这样的书中,UseNet组中以及朋友和同事中。从这些地方不仅可以获得信息,还可以得到实际的程序和库。有些程序和库如果已经有人做过了为什么自己还要从头再做一遍呢?但就像不能盲目听从别人的意见一样,关于如何理财,如何驾车或者生活中的别的方面,同样,也不能在自己的服务器上盲目地运行另从的代码。从Net上得到的脚本也可能真正是很好的脚本。但也许并不是。花些时间考察一下脚本的来源以及获取它的站点的可靠性是值得的。
4.1 追根求源
某些Web拥有者。如果不能看到并研究源代码的话,他们甚至都不会运行一个公共的、免费的或商业性的脚本。这可能有点偏激。如果某个声誉很好的公司销售一个文档详细且广为使用的脚本,该脚本应该比自己写的脚本更安全一些。原因有二。首先,专业人才知道并能避免一些常见的安全漏洞;其次,公司是为了嫌钱而做生意,如果他们以次充好或销售那些恶意的产品就不能再做生意赚钱了。
从另一方面来看,如果UseNet组中看到一个编译好的可执行文件出自一个从没听说过的人,没有什么文档可以看,也没有该程序的用户可以交流交流,那么在将它放入自己的服务器之前一定要仔细考虑。也有可能这是来自一个像自己一样的另一个CGI编程者的完全合法的贡献,目的是想让全世界共享他的编程成果。但它也可能来自某个恶意的,具有变态幽默感的,只想看到自己能使多少人清盘的人。
在评价公共的免费软件或商业性软件时,应考虑下面这些方面:
该脚本来自一个声誉好的站点吗?该站点存在很长一段时间了吗?它さ煤寐穑縒eb拥有者在发布文件前进行检查吗?
有没有足够的文档说明该程序如何工作以及用户如何使用等信息?
有多少人已经下载了该脚本?该站点愿意提供顾客名单吗?(仅在有疑问时才去询问;Web拥有者不会整天去回答这类问题。)
有人在UseNet上讨论该脚本吗?如果有,他们说好还是不好?如果没人提到该脚本可以进一步请求别人的见解。一般总会有人响应的。
提示
在评价脚本时检查下面这些useNet组: comp.security.announce,comp.securiy.unix,以及comp.infosystem.www.authority.cgi。另外还可以访问位于ftp.cert.org的Computer
Emergency Response Team,以了解安全问题的历史及有关工作以及安全保护的软件。
5)该脚本的作者有没有一些别的好名声的脚本?
6)源代码能得到吗?免费的或有价的都行。
7)该程序是不是过份宣传它的能力?如果是,这可能是一个编程新手。
8)该站点自己运了该脚本吗?如果没有,为什么?能找到别的站点运行该脚本吗?过分偏激以及时间限制
尽管游览取自Web的所有代码是个好主意,但要花费很多时间,特别是当代码比较复杂时更是如此。
例如,NCSA HTTPd就太大了,一般用户不可能一行行去读,但是从它的主站点http://www.ncsa.uiuc.edu下载它却能保证极好的完整性,满足任何用户的需要。实际上,任何从NCSA下载的东西都是有保障的。
实际上,Web上的许多著名的站点已经为用户做了大部分的几乎偏激的代码检查工作。从它闪中下载代码是可能利用的另一层另一层保护。这些站点包括:
ftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/cgi(the NCSA Archive)
http://www.novia.net/~geewhiz(Virtual Webwerx Division Zero-CGI Land)
http://www.lpage.com/cgi(the World-Famous Guestbook Server)
http://sweetbay.will.uiuc.edu/cgi++(cgi++)
http://www.aee.com/wdw(the Web Developers Warehouse)
4.2 注意礼貌
最后,如果确实希望从Web上下载一些CGI代码,或者完整地使用它,或者用作自己编写的更大程序的一部分,还应了解一些事情。
代码是兔费的并不意味着可以自由地用它作自己想做的任何事情。通常程序和库是禁止拷贝的,如果原始作者没有放弃这个权力,他即能限制如何使用该程序。例如,作者可能禁止拆散该脚本,及禁止用作别的脚本的一部分。
一跟来说,在使用别人的代码之前(即使已经确定它是安全的),最好与作者进行联系取得许可。至少这样做比较有礼貌。而大部分情况下,作者会很高兴他的代码能被别人利用。当然,如果在自己程序某个片段处注明原始作者将是很礼貌的。
|