如何解决绑定记录集实时更新存在安全隐患

Question

如何解决绑定记录集实时更新存在安全隐患
------------------------------------
在客户端进行记录编辑时,可以将字段绑定到控件(比如表格)上,这样用户操作时,只要下移一条记录,则这条记录会实时更新到后台,这本来是非常方便的功能,但是有一个安全性问题不知大家注意到没有,在实际中是如何解决的?
这个安全性是这样的:
假如我操作期间,这个单据执行了审核操作,则理论上是不能再被修改的.但是绑定记录集的情况下,还会修改数据的,因为绑定字段的更新是系统自动的,他不会是验证这个单据是否已经审核过,所以这就是一个安全问题.可能你会问,有这种可能性吗,没改完就审核,我可以负责任的说,完全有可能的.但并不是没做完单据就审核,而是要保证审核后,数据会立即受到保护.
说到这里,不得不说一下我们单位曾经请一个小公司开发的管理程序.这个程序很不严格,假如A用户打开了这个单据,但是有点事出去了,注意,A用户并没有关闭打开的程序.这时B用户从另一台机器打开这个单据进行修改,然后审核.可是过了2个小时,A用户回来了,但是他不知道单据已经改好了.但依然续续修改2小时前打开的单据,这个单据还是可以修改的,因为程序只判断打开单据时的审核状态.
通过我举的例子你可能明白我说的意思了吧.
比如A用户打开修改单据的窗体想对单据进行修改(表格与数据绑定,下移记录便会自动更新),可此时A用户有事出去一下,他并没有关闭已经打开的窗体,这时B用户从自已的机器上修改了A用户没改完的单据,并进行审核.过一会A回来了,他并不知道B已经帮他将单据做好了并审核,就继续修改单据.此时还是可以改的.可见审核操作并没有禁止A用户对记录的修改,这就会造成误操作呀.
实际中如何处理这个安全问题呢?

Answer 1

  工具的确提供了这种更新机制，但在实际应用中，不建议采用此种方式，采用批量更新方式，然后让根据实际需要，由用户干预或者由某种触发机制完成数据提交（生成SQL脚本进行更新，记录集只充当数据绑定、展现）。
  用户数据审验安全问题：这个也是可以控制的，不如，当用户审核完毕之后，提交数据之前，应该先判断原先数据状态，如果已经审核，则不允许再次修改审核，如果未审核，则执行审核，如果某数据已经被删除，则提示数据不存在等。

Answer 2

你已经在DotNet社区问过相同的问题。这个问题不是 什么安全隐患，而是根你的业务数据控制上有关。如果你还在把业务数据和UI数据混合，那你只有才去定时刷新数据。答案，我已经说了在DotNet版面中。在这里，我再次说说： UI 接受的数据只是View数据，它是一个或几个Model数据的集合。也就是说，传递给UI数据，用户在UI怎么变化，它也是个临时数据。只有当 UI将这些临时数据提交到Business Layer 进行业务处理时，如果符合业务数据规范保存后，才会形成真实的业务数据。
 也就是UI代码和业务 数据剥离，这才是治本之道。

Answer 3

这种问题我也遇到过！
设计问题~
这属于一种同步更新问题~
对于这种问题，我的解决方法是这样：
如果用户修改某数据后，应该在该条记录中加上只读锁~这样就保证当A离开时，B根本就打不开那条记录，其实就是建一个LockTable而已。
其实这种解决方法和VSS是一样的，只不过VSS控制的粒度是文件而已！

Answer 4

如果LZ的程序是3层的话，则可以用一个通知机制来解决！
当某用户A修改该记录后，在没有保存记录的情况下离开，B也打开了该记录，这时B修改记录后并保存，在保存后，
就应该做这些事：
1.获取当前连接SQL的Client IP
2.对Client IP进行发送消息，显示该记录已被修改并给出解决方法，这时用户A回来后，看到这个信息，也就会退出窗体，重新进入。

Answer 5

UI   接受的数据只是View数据，它是一个或几个Model数据的集合。也就是说，传递给UI数据，用户在UI怎么变化，它也是个临时数据。只有当   UI将这些临时数据提交到Business   Layer   进行业务处理时，如果符合业务数据规范保存后，才会形成真实的业务数据。 
  也就是UI代码和业务   数据剥离，这才是治本之道。
---------------------------
这位大哥说的非常有道理，也是理想化的程序~
但LZ说的问题并不是这样设计就能够解决的。
还有另一种方法：
就是在更新数据前，把WHERE A=.. B=..布及到各个字段，这样如果没有相应的数据被更新，就说明有人已经把该记录修改~