javscript：请问大家用什么library做input validation?

典

注意到我们系统里用的一些js validate函数(从网上下载的), 很多漏洞，
请问大家用什么library 做validation?

google 后发现网上贴的大部分都是不太可靠的，

只考虑前端页面，也就是说页面的input validation要100%可靠。

[ 本帖最后由 典 于 2011-9-6 10:25 编辑 ]

乱码

我原来用这个，可以用它现成的validation function, 也可以用自己的，感觉还行。

http://bassistance.de/jquery-plugins/jquery-plugin-validation/

800tiger

JS 本来就是不安全的啊，前台的VALIDATION 只是个辅助作用，还是CONTROLLER里处理VALIDATION靠谱些，毕竟是SERVER-SIDE。

典

原帖由 800tiger 于 2011-9-6 10:39 发表
JS 本来就是不安全的啊，前台的VALIDATION 只是个辅助作用，还是CONTROLLER里处理VALIDATION靠谱些，毕竟是SERVER-SIDE。

道理是这个道理，
可是我们正在做的一个东西几乎没有server 端，直接就是javascript程序了，然后就到数据库了，有点搞。。。anti-pattern, 但是开发快

乱码

原帖由 典 于 2011-9-6 10:47 发表


道理是这个道理，
可是我们正在做的一个东西几乎没有server 端，直接就是javascript程序了，然后就到数据库了，有点搞。。。anti-pattern, 但是开发快

你们的team个个都是高手！！

sydney很少能找到这种team了。

鱼羊鲜

既然只有前端检测 那就没有办法绝对安全了，鱼和熊掌
我用自己写的jq插件，比较小，可以自定义规则，够用了

huazhb

能不能告诉我你们做的什么网站阿?

典

原帖由 huazhb 于 2011-9-6 11:38 发表
能不能告诉我你们做的什么网站阿?

算不上网站，CRM里边的一个模块，一个离线使用的网页程序，鸡肋。。。

atransformer

典

原帖由 乱码 于 2011-9-6 10:58 发表


你们的team个个都是高手！！

sydney很少能找到这种team了。

算不上了高手，上不了场面，跟你们比差老远了

典

原帖由 鱼羊鲜 于 2011-9-6 11:13 发表
既然只有前端检测 那就没有办法绝对安全了，鱼和熊掌
我用自己写的jq插件，比较小，可以自定义规则，够用了

看来只能这样了

乱码

原帖由 典 于 2011-9-6 14:20 发表


算不上了高手，上不了场面，跟你们比差老远了

我们现在的team，碰到js的问题，很明显就信心不足，database也是相对软肋，readify的database design/implement是个joke.

不过.net这块很强，trouble shooting的能力也很强。

team member可以用强项相互cover，但好的developer不应该有很明显的弱点...

典

最简单的isNumber函数，这个看起来是接近权威的被很多人接受的，
http://stackoverflow.com/questio ... meric/174921#174921

可是我拿来一跑unit test, fail 一大堆。

jquery 的 validation, 下次再仔细看看，

典

原帖由 乱码 于 2011-9-6 14:30 发表


我们现在的team，碰到js的问题，很明显就信心不足，database也是相对软肋，readify的database design/implement是个joke.

不过.net这块很强，trouble shooting的能力也很强。

team member可以用强项相互cover，但好的developer不应该有很明显的弱点...

看你们公司还招人不? 我可以做javascript,顺便跟你学.net

乱码

原帖由 典 于 2011-9-6 14:48 发表


看你们公司还招人不? 我可以做javascript,顺便跟你学.net

请你过来给我们作TL吧

o2h2o

原帖由 典 于 2011-9-6 14:47 发表
最简单的isNumber函数，这个看起来是接近权威的被很多人接受的，
http://stackoverflow.com/questio ... meric/174921#174921

可是我拿来一跑unit test, fail 一大堆。

jquery 的 validation, 下次再仔细看看，

isnum　在　javascript　the　good　parts　里面提到了
典韦兄
可以翻翻看

典

原帖由 o2h2o 于 2011-9-7 12:44 发表

isnum　在　javascript　the　good　parts　里面提到了
典韦兄
可以翻翻看

那个是用来判断一个number  本身的，

input validation要做的是判断一个string 是不是能合法地转到number,

linkspeed

正在头疼一个validation问题。很奇怪的
html源码:
<textarea class="required" cols="100" id="t1" maxlength="250" name="t1" rows="5">
</textarea>

IE developer里面就是看不到“required”，
如果我手工在attribute里面输入required，就工作。
不输入就不工作。

dcc82

我用服务器端的zend validation以及zend filter两个ZF中的类库来做验证和过滤
我基本上不用客户端的验证，最主要的问题还是因为不可靠，在Greasemonkey，firebug等插件下往往会变的形如虚设，你根本没办法相信客户端提交过来的数 据，天知道被篡改成什么样子了。
我一直都觉得客户端的form validation只是锦上添花的东西，在客户端做主要是为了减轻服务器端的压力，但服务器端的验证是绝对不可少的，而且验证绝对要做的全面。所以如果只是小网站的话，本来流量就不大，而且受限于开发时间的限制，可以根本忽略客户端的验证，通过ajax到服务器端云验证足矣。
还有一点要考虑到的是，在有些需要禁用javascript的环境下，或是浏览器升级了造成不兼容了，或是javascript类库升级造成不兼容了，这时候如果用了第三方form validation的插件的话，很有可能因为javascript的一点点错误导致连整个表单都无法发送的情形

[ 本帖最后由 dcc82 于 2011-9-7 14:34 编辑 ]

鱼羊鲜

客户端的验证虽不可靠，但还是需要的

[ 本帖最后由 鱼羊鲜 于 2011-9-7 23:45 编辑 ]

阿Ka

How about regex to solve xss?

atransformer

如果关上javascript, 不就全完了吗？？
而且，客户端可以看到 all js codes. 一改不就完了？

dcc82

原帖由 dcc82 于 2011-9-7 14:21 发表
我用服务器端的zend validation以及zend filter两个ZF中的类库来做验证和过滤
我基本上不用客户端的验证，最主要的问题还是因为不可靠，在Greasemonkey，firebug等插件下往往会变的形如虚设，你根本没办法相信客户端提交过来 ...

再补充几点，我之所以认为客户端的验证不是必须的，还包括以下几点原因；
第一：你势必要写两套验证，客户端一套，服务器端一套。一个人写没问题，那要是frontend和backend是两个人分开来写的呢?当字段改变或新增了，维护上就是个问题。

第二：在做企业级开发的时候，很多时候会出现很复杂的表单，比如像物流定单这种。什么叫很复杂的表单？就是表单套子表单，然后子表单又分组，并且某些字段是ajax动态生成的。在这种情况下，客户端的验证绝对写死你，纯粹是吃力不讨好的事情。

第三：我目前所看到的客户端的验证还是仅限于结构单一的简单表单，比如像注册，登陆这种，这没问题。但是要注意的是，很多时候你并不能很有效的降低服务器的压力，比如说注册吧，你还是要到服务器云验证email或是username是否唯一性，这同样要占用资源。

所以总的来说，做客户端的验证只是为了降低服务器的压力，它决对不是必须的。

就我个人而言，我基本上不存在验证问题，因为所有的表单都是服务器端生成的，好处就是验证和过滤统统自动带上了，而且表单之间可以继承，很容易被复用，而frontend developer要干的只有一件事：css

典

看来看去还是用自己的东西可靠点, 基本上借用unobtrusive这一套,或者jquery的那套模式
1）在页面上，给需要validate的元素加 attribute, 比如<input tp="number"...  或者tp="int" / tp="email"  / tp="date"
2）然后在页面加载完后，用jquery给这些元素附加 validate event,
比如$("input[tp='int'"]).bind("keyup change"， ....
这样，用户做任何输入都能立马得到validate,
3) 如果输入非法，马上改变这个element的颜色，或者在旁边显示一条error提示，并设置这个element 的attribute: $(this).attr("error","1")

4) 在整个页面完成前，比如submit前，用jquery查找页面上的error，如果有error就不允许提交页面


这里有一个差不多的，研究一下...
http://www.javascript-coder.com/html-form/javascript-form-validation.phtml

[ 本帖最后由 典 于 2011-9-8 13:54 编辑 ]

kr2000

我个人的经验是前端验证比后台验证用的多
前端验证以及一些form帮助才是用户直接感受到的

最近刚开始新工作, 做公司内部系统
刚做了两个小项目, 完全没有做后台验证
后台就是解决一点安全问题

当然, 外部网站就要求要高的多了

listeningcn

原帖由 乱码 于 2011-9-6 14:30 发表


我们现在的team，碰到js的问题，很明显就信心不足，database也是相对软肋，readify的database design/implement是个joke.

不过.net这块很强，trouble shooting的能力也很强。

team member可以用强项相互cover，但好的developer不应该有很明显的弱点...

Aaron Powell对于JS应该是很不错的吧。这次TechEd很多从你们公司来的呢

showen

客户端验证还是很有必要的，你要是遇上正常的user,那就是客户端一遍验证，然后服务器端一遍验证，数据进数据库了。

你要是遇上sb一点的user那就郁闷了，客户端没验证加上N遍服务器端验证，还是有不小的影响的。

showen

关于 mvc3 里面这个unobtrusive 验证，

在model里面定义validation的logic,然后客户端会自动生成相应的validation，这样只用把validation写在一个地方。

不知道有没有人用这种方法在项目里面的，对于复杂验证好不好实现

zhilaohu

客户端验证可以减少服务器段的load, 提高用户满意度， 基本的输入错误在客户段就提醒用户比发到服务器端占用服务器资源有利的多， 毕竟大部分用户都不是黑客。服务器端验证自然也不能少， 系统安全不能忽视阿。