使用jsp完成文件可定制上载

2008-02-23 07:46:47来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

  这几天的工作主要围绕着文件(主要是图片)上载,并可以在线和HTML编辑器集成,操作简便与目前引用网上图片相似。我是有点小看了这件事情,不过也不无道理:一来以前使用servlet完成过,其中的核心DoUpLoadBean也的确是可以工作;其次集成到编辑器则在使用php的本人的私人博客上做过,看不出有什么特别难的地方。但实际上在展开后就发现,简单实现上载是容易的,但要合理地安排上载的策略,就不得不小心翼翼。因为允许上载本身是非常需要危险的,这实际上是开了一个口子;允许客户对服务器进行事实上的操作,上载攻击从来就不是一件困难,更不是一件罕见的事情;可以想见一旦系统开通,这类攻击必然就会发生。

  另一方面,在允许用户上载本地文件同时就必须考虑后期的管理,因为,即使是在用户本地,最大的硬盘也会过不多久就会给说不清是什么东西的垃圾占满;何况现在是允许许多人同时使用的服务器,如果没有精确的策略,花不了多长时间,客户的上载文件就会把系统撑爆。就在上一个星期,一位朋友向我求助,说是他们的数据库达到30G,把硬盘吃光了,结果死了机;对此,本人只能是爱莫能助,因为,可以肯定里面绝大部分是垃圾,却搞不清什么是垃圾,什么是必须的。因为,他们缺乏一个策略。而且,就算用户不是恶意的,大部分情况下,在开通开载的时侯,很快硬盘也会撑满,如果这是系统盘,通常就意味着崩溃,可见,必须使用连接把上载限制到另一个专用的分区,以确保安全。通常铁quota在这里是派不上用场的,因为那需要把WEB帐号与操作系统帐号结合,既复杂又危险,更加没有这个必要。同时,上载的文件如果不是给每个用户分配目录,也应该是在每个用户的名称前增加一个前缀,以供识别;这样,万一需要清理,配合文件日期,可以使用find/grep/rm组合脚本进行备份或清除,至少是有可能的。

  还有其他因素,导致上载文件实际操作比简单接爱一个文件上载的程序量要大得多;其中主要包括权限控制,(考虑到可以用上载进行攻击,这条不得不小心点),文件管理,以及修改属性,包括大小,类型限制,可以方便修改存储的方式等等,事实上,就完成情况下,上载部分只花了五行程序,而管理则不小于50行。

  今天已经不必再自已写输入流了,就算自已没有积累,还是可以从网上找到开源的代码,象jakarta commons upload就是一个。这个东西没有什么例子,所找到的例子大部分是跑不动的,倒不是怪程序员自已,而是这个东西不但没有什么文档,还把方法和类也改了:例子说的UpLoad实际上是DiskUpload,而当前的Upload有什么区别,为什么可以省去设置内存耗量的等部分,我找不到任何的解释。虽然对自已的代码有所偏爱,但由于我的代码不能处理多个file上载,虽然,这种情况实际上也很少,我却一直弄不明白有什么办法可以识别不止一个上载请求,这意味着我对RFC1864仍是欠了解的,既然有更可靠的东东,就不要太偏心自已的东西了,结果把用了几年的DoUploadBean彻底地埋葬了。

  在选择是使用jsp还是servlet处理上载时,显然两者中servlet更规范一点,但在权限控制上颇为不便,因为,所以识别变量必须通过 request获取,这也意味着存在客户端伪造变量直接提交上载的可能性,确保正确识别意味着大量的代码。我最终决定采用自已发明的使用jsp标签取代 servlet的办法,(参看《可以使用多个jsp标签达到类似servlet效果》一文)。结果表明,这的确是兼有 jsp/servlet/javabean优点的好办法,特别是修改非常容易,我改个主意要以用户名称开目录,只是改了标签一个定义属性就搞妥了,这才真是易用性的体现。

  最终的使用方法很简单:

<command:saveupload byform="false" noredirect="true" filename="theimg" roles="SECTION" dir="${filepath}" max="20000000"/>

  这样,saveupload标签就会自动检测权限,并按科室中定义的管理组允许其中的成员上载,上载到科室下的upload目录中的用户名称建立的专用目录中,而存盘的文件名使用theimg名称供客户端嵌进正在编辑的文本中。

  这样,上载就真正成为一个可以自由方便地使用的组件了。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:JSP访问数据库的问题整理

下一篇:标签库完成复杂的后台处理功能的JSP示例