举例说明:登录界面,登录账户(账户名称,密码)。众所周知,该界面要有基本的数据验证,为空验证,字符长度大小验证等等,但是在进行账号和密码验证登陆时,往往系统会给出统一的一个弹框或者错误提示框提示用户名或者密码有错误,我比较困惑的是:为什么不能把账户不对和密码错误的提示进行分开,分别展示在对应的输入框下面呢?我周围有同事说,
“不要在服务端决定客户端要显示的内容”,所以他建议使用弹框进行统一提示,不用分别提示;还有就是在调用业务服务前,调用单独的服务进行专门的验证。我感觉(1)方法特别影响用户体验,(2)方法还是需要多调用一次服务,影响系统性能。应该很多业务系统的基础数据都需要唯一性或者重复性的验证,但是这些需要调用服务查询数据库进行验证的提示到底该怎么做比较好呢?大家有没有好的想法可以分享一下呢
用户体验不是建立在牺牲安全性的基础上
性能只是一个技术性问题,基本不能因为性能问题去压制业务,唯一能够使用的场景是在性能的确无法支撑的时候两边进行妥协最后达成一致
服务端的确不应该左右客户端显示,如果你这样搞了服务适应性就会很差,很难去兼容不同客户端的需求
那关于db数据验证该怎么做呢?我只是拿登录做个例子,真正想了解的还是db数据验证。以你的意思验证提示统一弹框比较好吗?
@简单笑容: db操作和你界面上是两个事吧
db如何操作这个是跟着你逻辑走的,在你这个例子中直接带用户提交上来的用户名密码(密码规则代码中做)去匹配就完了,代码逻辑判断取出来的数据行数
如何展示这个是界面上的事,你只需要返回给调用方一个简单的code,由调用方自己根据code去呈现
模糊地提示用户名或者密码有错误是出于安全考虑的!
我只是举个例子,那关于db数据验证怎么做比较好?如果不使用服务端返回的验证消息,怎么做才合理呢
并没有不好,你在提交登录的时候就可以js校验长度,大小写,填写不合格就不让提交,后台统一返回密码或者用户名错误,至于具体哪个环节错误,log打印就好,一般不会把错误码和对应的msg返回给前端弹出的;至于需要查询db数据校验,把数据刷到缓存就好,写一个统一的校验方法调用
你说的把数据刷到本地缓存是不是消耗就比较大了呢,毕竟一个真正的业务系统数据表数据还是挺多的
你可以站在这个角度去看这个问题,前台js验证只是为了温馨提醒普通用户,而最终的验证由后台控制是为了防止不速之客的。且前台的验证不会带来任何的性能问题,都是在客户机上做的验证。