我将为企业制作一个小型应用程序，用于本地扫描，并将文档存储在位于本地计算机或同一 LAN 中的计算机上的数据库中。
我可以创建一个名为 Users 的表，其中包含用户名和密码，并根据用户类型 ID 显示一个表单或另一个表单。但我对经验丰富的程序员推荐的方法更感兴趣。
有什么建议吗？
编辑：我正在寻找足够安全但也足够可扩展的东西。
I'm going to make a small application for a business that will be used locally for scanning, and storing documents in a database located on the local machine or on a machine located in the same LAN.
I could create a table called Users with username and password and according to the usertype ID show a form, or another form. But I'm more interested in the recommended approach by seasoned programmers.
Any advice?
Edit: I'm looking for something that will be secure enough, but also extensible enough.
发布评论
评论（5）
如果只是简单的应用，就不要用宇宙飞船过马路。
创建以下数据库架构：
Users ：用户名和哈希密码
Roles ：RoleName、RoleID、RoleStrength(int)
RolesMembership ：包含 userid 的 Rolemembership 表和roleid以允许未来的多个成员资格。
设置角色时，给他们一个数字权重。即：Admins = 1000，Power-users = 500，guests = 10。这样，在您的表单上，您可以说，如果用户级别为500或以上，则设置完整视图，否则，仅查看或无访问权限。
更好的是，使用带有 IsPowerUser 或 IsAdmin 等方法的安全类将其抽象出来。
它简单、可读且可重用。
If it's just a simple application, don't use a spaceship to cross the road.
Create the following DB schema:
Users : username and hashed password
Roles : RoleName, RoleID, RoleStrength(int)
RolesMembership : Rolemembership table that contains userid and roleid to allow for future multiple membership.
When setting up roles, give them a numeric weight. ie: Admins = 1000, Power-users = 500, guests = 10. This way, on your forms, you can say, if user level is 500 or above, set full view, otherwise, view only or no access.
Better yet, abstract it out with a security class with methods like IsPowerUser, or IsAdmin.
It's simple, readable and reusable.
即使我不能认为自己“经验丰富”，我也会给出我的答案，因为这几周我面临着同样的问题。
我将定义一个权限掩码来识别允许的操作，将其关联到角色组，然后将用户关联到组。权限掩码更完整，组定义中允许更细粒度。
这样，多个用户就有一个权限定义，这比使用每个用户类型基础定义角色更好，因为权限掩码可以修改和扩展。
更复杂的方案是可能的，这可以允许每个用户的权限覆盖组权限，或者层次结构权限掩码，以便定义能够管理组权限的主管用户。
这些模型的应用取决于所需的可扩展性和系统的用户数量。
Even I cannot consider myself "seasoned", I would give my answer since I'm facing the same problem in these weeks.
I would define a permission mask in order to identify allowed operations, associate it to role groups, and then associate users to the groups. More complete is the permission mask, more granularity is allowed in the group definition.
In this way there is one permission definition for multiple users, which is better than define the role using a per-user type basis, since the permission mask can be modified and extended.
More complex schemes could be possible, which could allow per-user permission overriding group permission, or hierarchy permission masks in order to define supervisor users able to manage group permissions.
The application of these models depends by the required scalability and by the number of users of the system.
听起来对我来说是一个合理的方式。只需记住对密码进行哈希处理即可。
我还将表单中的公共控件组件化，以便您可以重用公共部分。
Sounds like a reasonable way to go to me. Just remember to hash the passwords.
I would also componentize the common controls in the forms, so you can reuse the common parts.
如果您使用的是 Visual Studio，我将只使用内置的成员资格提供程序。这将自动处理您的数据库和所有内容。无需重新发明轮子。
If you are using Visual Studio, I would just use the built in Membership providers. That would take care of your database and everything automatically. No need to reinvent the wheel.
虽然面向 ASP.NET，但我强烈建议您查看这篇文章：https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
您可以使用内置的成员资格和角色对象（即使在桌面应用程序中）来定义您自己的权限模式。使用此功能可以省去为用户（和角色）表创建自己的数据库条目的麻烦，同时还可以为您处理密码散列（从而使应用程序更安全）。
最后，您可能需要阅读 MSDN 官方文章：
关于“会员身份”： http: //msdn.microsoft.com/en-us/library/yh26yfzy.aspx
关于“角色”：http://msdn.microsoft.com/en-us/library/ff647401.aspx
Although orientated towards ASP.NET, I'd thoroughly recommend checking out this article: https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
You can use the in-built Membership and Roles objects (even in a desktop application) to define your own schemas of privilege. Using this feature takes the hassle out of creating your own database entries for the Users (and Roles) tables, while also handling password hashing for you (leading to more secure applications).
Lastly, official MSDN articles you might want to read:
On "Membership": http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
On "Roles": http://msdn.microsoft.com/en-us/library/ff647401.aspx