34,590
社区成员
发帖
与我相关
我的任务
分享用同一个帐号同时在多个客户端登录，和用不同的帐号同时登录有什么区别？
假设网络中有基于MS SQL Server的C/S系统，N个客户端都用同一个帐号登录跟分别用不同的帐号登录有何区别？
...全文
请发表友善的回复…
发表回复
samuelpan 2003-10-23
- 打赏
- 举报
用一个普通的只读用户在客户端连接数据库。
然后在程序中更换一个较大权限如sa的用户重新登入数据库。
然后在程序中更换一个较大权限如sa的用户重新登入数据库。
lvltt 2003-10-23
- 打赏
- 举报
学习
Veeve 2003-10-23
- 打赏
- 举报
普通用户的话有建库的权限吗？有建表的权限吗？
（我现在是这么做的：
(1)用sa的帐号登录创建数据库[假设为testdb]、创建一个特殊的login[假设为app_user,默认数据库为testdb];
(2)用sp_grantdbaccess为app_user建立数据库用户;
(3)用sp_addrolemember为app_user赋db_owner角色;
(4)用app_user登录创建表并初始化数据;
(5)客户端运行时先通过app_user登录数据库，再通过我自己的权限管理系统检查，然后正常运行;
）
这样做合理吗？
（我现在是这么做的：
(1)用sa的帐号登录创建数据库[假设为testdb]、创建一个特殊的login[假设为app_user,默认数据库为testdb];
(2)用sp_grantdbaccess为app_user建立数据库用户;
(3)用sp_addrolemember为app_user赋db_owner角色;
(4)用app_user登录创建表并初始化数据;
(5)客户端运行时先通过app_user登录数据库，再通过我自己的权限管理系统检查，然后正常运行;
）
这样做合理吗？
pengdali 2003-10-22
- 打赏
- 举报
这个系统的所有客户端通过同一个login登录，为这个login赋最大数据库存取权限。
建议你建立一个普通用户，用这个用户建库建表建你要的所有东西，这样你的所有客户端只可以访问这个库中所有东西。
建议你建立一个普通用户，用这个用户建库建表建你要的所有东西，这样你的所有客户端只可以访问这个库中所有东西。
Veeve 2003-10-22
- 打赏
- 举报
to: pengdali(大力 V3.0)
“权限设置，我认为你不应该依靠数据库级的权限设置，你的应用最好有自己的权限系统。这样才够灵活。”
事实上正是如你所说，我想不依赖数据库级的权限管理，我打算在我的应用中维护自己的权限系统。
我是这样设想的，这个系统的所有客户端通过同一个login登录，为这个login赋最大数据库存取权限，在这个基础上由我自己的权限系统维护用户的权限。我想弄明白的就是这样做原则上是不是可行？会不会有什么不良影响？正确的做法是否如此？
“权限设置，我认为你不应该依靠数据库级的权限设置，你的应用最好有自己的权限系统。这样才够灵活。”
事实上正是如你所说，我想不依赖数据库级的权限管理，我打算在我的应用中维护自己的权限系统。
我是这样设想的，这个系统的所有客户端通过同一个login登录，为这个login赋最大数据库存取权限，在这个基础上由我自己的权限系统维护用户的权限。我想弄明白的就是这样做原则上是不是可行？会不会有什么不良影响？正确的做法是否如此？
txlicenhe 2003-10-21
- 打赏
- 举报
应该是一样的。
pengdali 2003-10-21
- 打赏
- 举报
多个线程，你通过下面查看：
sp_who2
sp_who2
yown 2003-10-21
- 打赏
- 举报
创建不同的角色或创建不同的组
zarge 2003-10-21
- 打赏
- 举报
建立应用程序安全性和应用程序角色
新增信息 - SQL Server 2000 SP3。
Microsoft® SQL Server™ 中的安全系统在最低级别，即数据库本身上实现。无论使用什么应用程序与 SQL Server 通讯，这都是控制用户活动的最佳方法。但是，有时必须自定义安全控制以适应个别应用程序的特殊需要，尤其是当处理复杂数据库和含有大表的数据库时。
此外，可能希望限制用户只能通过特定应用程序（例如使用 SQL 查询分析器或 Microsoft Excel）来访问数据或防止用户直接访问数据。限制用户的这种访问方式将禁止用户使用应用程序（如 SQL 查询分析器）连接到 SQL Server 实例并执行编写质量差的查询，以免对整个服务器的性能造成负面影响。
SQL Server 通过使用应用程序角色适应这些要求。应用程序角色与标准角色有以下区别：
应用程序角色不包含成员。
不能将 Microsoft Windows NT® 4.0 或 Windows® 2000 组、用户和角色添加到应用程序角色；当通过特定的应用程序为用户连接激活应用程序角色时，将获得该应用程序角色的权限。用户之所以与应用程序角色关联，是由于用户能够运行激活该角色的应用程序，而不是因为其是角色成员。
默认情况下，应用程序角色是非活动的，需要用密码激活。
应用程序角色不使用标准权限。
当一个应用程序角色被该应用程序激活以用于连接时，连接会在连接期间永久地失去数据库中所有用来登录的权限、用户帐户、其它组或数据库角色。连接获得与数据库的应用程序角色相关联的权限，应用程序角色存在于该数据库中。因为应用程序角色只能应用于它们所存在的数据库中，所以连接只能通过授予其它数据库中 guest 用户帐户的权限，获得对另一个数据库的访问。因此，如果数据库中没有 guest 用户帐户，则连接无法获得对该数据库的访问。如果 guest 用户帐户确实存在于数据库中，但是访问对象的权限没有显式地授予 guest，则无论是谁创建了对象，连接都不能访问该对象。用户从应用程序角色中获得的权限一直有效，直到连接从 SQL Server 退出为止。
若要确保可以执行应用程序的所有函数，连接必须在连接期间失去应用于登录和用户帐户或所有数据库中的其它组或数据库角色的默认权限，并获得与应用程序角色相关联的权限。例如，如果应用程序必须访问通常拒绝用户访问的表，则应废除对该用户拒绝的访问权限，以使用户能够成功使用该应用程序。应用程序角色通过临时挂起用户的默认权限并只对他们指派应用程序角色的权限而克服任何与用户的默认权限发生的冲突。
应用程序角色允许应用程序（而不是 SQL Server）接管验证用户身份的责任。但是，SQL Server 在应用程序访问数据库时仍需对其进行验证，因此应用程序必须提供密码，因为没有其它方法可以验证应用程序。
如果不需要对数据库进行特殊访问，则不需要授予用户和 Windows NT 4.0 或 Windows 2000 组任何权限，因为所有权限都可以由它们用来访问数据库的应用程序指派。在这种环境下，假设对应用程序的访问是安全的，则在系统范围内统一使用指派给应用程序角色的密码是可能的。
安全说明 使用应用程序角色时，不能审核单个用户的活动，只能审核应用程序角色的活动。
有几个选项可用于管理应用程序角色密码而不是将其硬编码到应用程序中（不推荐使用）。例如，可以使用存储在注册表（或 SQL Server 数据库）中的加密键，只有应用程序有加密键的解密代码。应用程序读取键，对其进行解密，并使用其值设置应用程序角色。如果使用多协议 Net-Library，则含有密码的网络数据包也可以被加密。另外，当角色被激活时，可以在发送到 SQL Server 实例前将密码加密。
如果应用程序用户使用 Windows 身份验证模式连接到 SQL Server 实例，则在使用应用程序时，可以使用应用程序角色设置 Windows NT 4.0 或 Windows 2000 用户在数据库中拥有的权限。这种方法使得当用户使用应用程序时，对用户帐户的 Windows NT 4.0 或 Windows 2000 审核及对用户权限的控制容易维护。
如果使用 SQL Server 身份验证，并且不要求审核用户在数据库中的访问，则应用程序可以更容易地使用预定义的 SQL Server 登录连接到 SQL Server 实例。例如，订单输入应用程序验证运行该应用程序的用户，然后用相同的 OrderEntry 登录连接到 SQL Server 实例。所有连接都使用同一登录，相关权限授予该登录。
安全说明 应用程序角色可以两种身份验证模式运行。如果可能，请使用 Windows 身份验证。
示例
作为应用程序角色使用的示例，假设用户 Sue 运行销售应用程序，该应用程序要求在数据库 Sales 中的表 Products 和 Orders 上有 SELECT、UPDATE 和 INSERT 权限，但她在使用 SQL 查询分析器或任何其它工具访问 Products 或 Orders 表时不应有 SELECT、INSERT 或 UPDATE 权限。若要确保如此，可以创建一个拒绝 Products 和 Orders 表上的 SELECT、INSERT 或 UPDATE 权限的用户-数据库角色，然后将 Sue 添加为该数据库角色的成员。接着在 Sales 数据库中创建带有 Products 和 Orders 表上的 SELECT、INSERT 和 UPDATE 权限的应用程序角色。当应用程序运行时，它通过使用 sp_setapprole 提供密码激活应用程序，并获得访问 Products 和 Orders 表的权限。如果 Sue 尝试使用除该应用程序外的任何其它工具登录到 SQL Server 实例，则将无法访问 Products 或 Orders 表。
新增信息 - SQL Server 2000 SP3。
Microsoft® SQL Server™ 中的安全系统在最低级别，即数据库本身上实现。无论使用什么应用程序与 SQL Server 通讯，这都是控制用户活动的最佳方法。但是，有时必须自定义安全控制以适应个别应用程序的特殊需要，尤其是当处理复杂数据库和含有大表的数据库时。
此外，可能希望限制用户只能通过特定应用程序（例如使用 SQL 查询分析器或 Microsoft Excel）来访问数据或防止用户直接访问数据。限制用户的这种访问方式将禁止用户使用应用程序（如 SQL 查询分析器）连接到 SQL Server 实例并执行编写质量差的查询，以免对整个服务器的性能造成负面影响。
SQL Server 通过使用应用程序角色适应这些要求。应用程序角色与标准角色有以下区别：
应用程序角色不包含成员。
不能将 Microsoft Windows NT® 4.0 或 Windows® 2000 组、用户和角色添加到应用程序角色；当通过特定的应用程序为用户连接激活应用程序角色时，将获得该应用程序角色的权限。用户之所以与应用程序角色关联，是由于用户能够运行激活该角色的应用程序，而不是因为其是角色成员。
默认情况下，应用程序角色是非活动的，需要用密码激活。
应用程序角色不使用标准权限。
当一个应用程序角色被该应用程序激活以用于连接时，连接会在连接期间永久地失去数据库中所有用来登录的权限、用户帐户、其它组或数据库角色。连接获得与数据库的应用程序角色相关联的权限，应用程序角色存在于该数据库中。因为应用程序角色只能应用于它们所存在的数据库中，所以连接只能通过授予其它数据库中 guest 用户帐户的权限，获得对另一个数据库的访问。因此，如果数据库中没有 guest 用户帐户，则连接无法获得对该数据库的访问。如果 guest 用户帐户确实存在于数据库中，但是访问对象的权限没有显式地授予 guest，则无论是谁创建了对象，连接都不能访问该对象。用户从应用程序角色中获得的权限一直有效，直到连接从 SQL Server 退出为止。
若要确保可以执行应用程序的所有函数，连接必须在连接期间失去应用于登录和用户帐户或所有数据库中的其它组或数据库角色的默认权限，并获得与应用程序角色相关联的权限。例如，如果应用程序必须访问通常拒绝用户访问的表，则应废除对该用户拒绝的访问权限，以使用户能够成功使用该应用程序。应用程序角色通过临时挂起用户的默认权限并只对他们指派应用程序角色的权限而克服任何与用户的默认权限发生的冲突。
应用程序角色允许应用程序（而不是 SQL Server）接管验证用户身份的责任。但是，SQL Server 在应用程序访问数据库时仍需对其进行验证，因此应用程序必须提供密码，因为没有其它方法可以验证应用程序。
如果不需要对数据库进行特殊访问，则不需要授予用户和 Windows NT 4.0 或 Windows 2000 组任何权限，因为所有权限都可以由它们用来访问数据库的应用程序指派。在这种环境下，假设对应用程序的访问是安全的，则在系统范围内统一使用指派给应用程序角色的密码是可能的。
安全说明 使用应用程序角色时，不能审核单个用户的活动，只能审核应用程序角色的活动。
有几个选项可用于管理应用程序角色密码而不是将其硬编码到应用程序中（不推荐使用）。例如，可以使用存储在注册表（或 SQL Server 数据库）中的加密键，只有应用程序有加密键的解密代码。应用程序读取键，对其进行解密，并使用其值设置应用程序角色。如果使用多协议 Net-Library，则含有密码的网络数据包也可以被加密。另外，当角色被激活时，可以在发送到 SQL Server 实例前将密码加密。
如果应用程序用户使用 Windows 身份验证模式连接到 SQL Server 实例，则在使用应用程序时，可以使用应用程序角色设置 Windows NT 4.0 或 Windows 2000 用户在数据库中拥有的权限。这种方法使得当用户使用应用程序时，对用户帐户的 Windows NT 4.0 或 Windows 2000 审核及对用户权限的控制容易维护。
如果使用 SQL Server 身份验证，并且不要求审核用户在数据库中的访问，则应用程序可以更容易地使用预定义的 SQL Server 登录连接到 SQL Server 实例。例如，订单输入应用程序验证运行该应用程序的用户，然后用相同的 OrderEntry 登录连接到 SQL Server 实例。所有连接都使用同一登录，相关权限授予该登录。
安全说明 应用程序角色可以两种身份验证模式运行。如果可能，请使用 Windows 身份验证。
示例
作为应用程序角色使用的示例，假设用户 Sue 运行销售应用程序，该应用程序要求在数据库 Sales 中的表 Products 和 Orders 上有 SELECT、UPDATE 和 INSERT 权限，但她在使用 SQL 查询分析器或任何其它工具访问 Products 或 Orders 表时不应有 SELECT、INSERT 或 UPDATE 权限。若要确保如此，可以创建一个拒绝 Products 和 Orders 表上的 SELECT、INSERT 或 UPDATE 权限的用户-数据库角色，然后将 Sue 添加为该数据库角色的成员。接着在 Sales 数据库中创建带有 Products 和 Orders 表上的 SELECT、INSERT 和 UPDATE 权限的应用程序角色。当应用程序运行时，它通过使用 sp_setapprole 提供密码激活应用程序，并获得访问 Products 和 Orders 表的权限。如果 Sue 尝试使用除该应用程序外的任何其它工具登录到 SQL Server 实例，则将无法访问 Products 或 Orders 表。
pengdali 2003-10-21
- 打赏
- 举报
权限设置，我认为你不应该依靠数据库级的权限设置，你的应用最好有自己的权限系统。这样才够灵活。
Veeve 2003-10-21
- 打赏
- 举报
to pengdali(大力 V3.0):我知道你的意思，请问就这点区别吗？我的目的是想应用在我的C/S应用系统中，简化角色、用户、权限的管理，可行吗？
pengdali 2003-10-21
- 打赏
- 举报
企业管理器-->你的sqlserver实例-->管理-->当前活动。
Veeve 2003-10-21
- 打赏
- 举报
有更具体的看法吗？
