安全性问题

阿罗

客户端用户，可以自行连接sql服务器创建adp项目，取得服务器上可用表、关系、视图、函数、存储过程等一系列资源，从而可以知道很多额外信息，也很有可能做出规则不允许的事情。

例如销售合同报表在打印（发送）前需要经过审批，如果审批字段没有设置相应的权限，那么一个聪明的用户可以自行修改审批字段；更有可能，即使审批字段不允许修改，他还可以绕过这个字段，自行制作一份自己的报表。

我想到的一个办法，就是使用一些迷惑性的字段名称。有什么更好的建议么？

majian77

安全永远是相对的，不可能有绝对的安全。

cg1

你不应该把sqlserver的sa权限开给他，应该针对各种操作给予各种权限

阿罗

解决方法是这样的：

通常意义下的数据库角色，除了让用户能够使用用特定的应用程序，用户同时也可以在授权范围内对数据库自行进行查询等操作。但是，你并不总是希望用户这么做。例如，1楼所举的例子，另外还例如在一个负荷沉重的服务器上，你不希望用户作一些低质量的查询。

应对上述问题，大概有两种解决办法，
第一，用户实际登陆的账号没有任何察看和修改数据的权限，登陆以后，用程序来进行另外一个连接，而这个连接是用户不知晓的，并被授予相应的权限，更多的限制可能需要归到窗口控件级。但是，这个解决方案，在sql服务器仅使用trusted_connection的时候，是无能为力的，同时也很难区别不同的用户。
第二，使用sql服务器的应用程序角色。这个有一大堆东西可以讨论，但细节请自行察看sql帮助文档。应用程序角色，同其他普通角色不同，他们并不包含任何用户，相反，用户还是用他们自己的登陆方式登陆服务器，然后，通过执行sp_setapprole来激活这个特殊角色。在应用程序角色激活以后，用户本身的登陆在整个应用程序连接过程中完全失效，从而保证了用户不能从应用程序以外再次登陆服务器。
在Access ADP 中，基本程序（没有连接判断、错误控制句柄等）可能是这样的（首先在sql服务器中创建这个角色，例如testApp，密码mypass）：
Private Sub ActivateAppRole()
      Dim TSQL As String
      TSQL = "EXEC sp_setapprole 'testApp', {Encrypt N 'mypass'}, 'odbc'"
      Application.CurrentProject.Connection.Execute TSQL
End Sub
当然，可以用sp_addapprole, sp_dropapprole来编程创建应用程序角色，也同其他角色类型一样可以对其授权。

值得注意的是，在开发时，如果使用这个方案，由于adp通常用3个连接同服务器器通讯，其中第一个是程序启动后在内建数据库窗口建立可浏览对象因此无法对其进行setapprole，但是这并不重要，因为你以后不可能让用户显示这个窗口的（更有可能你用ade发行），而第二个连接和第三个连接（第三个连接通常是获取combo, list, reports）按照上述代码处理。另外，还有一些问题，例如子窗体不能正确联动。这是因为access通常（但并不总是）会创建新的连接来处理子窗体。因此，子窗体不能采用绑定，而必须手工编程。对于一个小型系统来讲，编码的量大大增加了。而对于一个庞大的应用来说，由于所有的查询都写了存储过程，窗体本来就不用绑定，因此可以想象采用应用程序角色是非常合理的选择。