Question

在采用MVP模式的Windows窗体工资单应用程序中（对于小规模客户端）我正在按如下方式规划用户权限处理。（基于滚动）

注意：少数用户可以同时使用系统（最多3个），数据库位于服务器端。

数据库中的用户表。

USER (user_id[pk], name, access_level, status)

PERMISSION (permission_id[pk], permission_detail)

USER_PERMISSION (user_id[pk][fk], permission_id[pk][fk])

我会维护USER表中的用户列表和PERMISSION表中的权限列表（权限详细信息是可访问的模块名称）。中间表USER_PERMISSION将使用权限映射用户。 UESR和PERMISSION表格与1:M表格有USER_PERMISSION个关系。

当用户登录系统时，首先系统将验证用户是否有效，然后将显示主屏幕，并且记录的用户的ID将保存在全局变量中（所有演示者均可访问）课程）。当用户尝试访问特定模块时，系统将读取该全局变量以查找当前用户的ID，然后它将在USER_PERMISSION表中查找是否存在与该用户ID相关的条目以及用户尝试登录的模块名称。如果有和入口，则用户将被授予对该特定模块的访问权限。

当用户注销时，将清除保存当前用户ID的变量。

在这种方法中，可以将当前用户的ID保存在应用程序内存中吗？或者应该写入本地文件？
应该跟踪对表中数据的修改，为此，我应该在每个表上保留一个单独的列（应该监视一个列）以保存正在修改的用户的ID记录？

修改：

我们可以使用SQL-SERVER用户名/登录吗？并且此用户操作登录内容是否可以移交给SQL-SERVER？

在Read/Write中控制Forms权限时，相应的Presenter会处理逻辑并设置View中的属性（IsModifyAllowed{get;set;}等属性，{{ 1}}等）根据当前用户权限。因此，View可以通过IsDeleteAllowed{get;set;}中的enabling / disabling控制器来处理剩下的事情。

在这种方法中，每个模型都应该具有匹配的属性，就像在视图中一样（在这种情况下为View等）？
在这种情况下，使用最广泛的方法是什么？

Answer 1

您在问题的第一部分中所描述的内容非常常见，尽管它实际上不是基于角色的，而是基于权限的。

虽然没有安全机制，但这并不是一个完美的解决方案。但它很简单而且很有效。

回答你的问题。

将id保存在内存中应该没有问题，只要我们不在这里讨论政府级别的安全性，并且没有真正担心人们闯入机器并试图获取访问权限，哪种情况下可能有更大的鱼要炸。将它存储在文件中实际上可能会降低其安全性，并且最终还是必须在某些时候将其读入内存。
跟踪更改可能很简单，也可能很复杂，具体取决于您的操作方式。您可以添加最后修改的字段，但这只会跟踪最近的更改。为了安全起见，您需要一个跟踪所有更改并保留数据历史版本的审计表。使用触发器执行此审计表可能是个好主意，这样您的应用程序代码就不必记住这样做。
是的，您可以使用SQL服务器登录和角色，但这可能不会使事情变得更容易或更简单。使用您的模型，您可以通过权限表控制对模块的访问。使用SQL Server角色，您必须通过数据控制访问，并对因无法访问事物而抛出的异常做出反应，或者在数据库中查询角色，并且必须在表中执行操作。如果您有Windows域，则可能需要考虑使用Active Directory。
我没有完全按照您对视图和模型属性的说法，因为您没有充分解释您的模型。
没有“最广泛使用的方法”，每个人都有不同的方式。虽然人们往往会做很多事情。 Microsoft提供了许多方法，例如，它们具有所谓的复合UI应用程序块和授权管理器。你可以在这里阅读一个有趣的实例：Granular Role Based Security。 Jesse Liberty提供了另一个Here

简而言之，这是你必须自己解决的问题，因为人们已经有成千上万的方式（如果不是数百万）。做一些研究，并试着想出在你的情况下最有效的方法。

应用程序中基于角色的用户权限处理

1 个答案: