0

我需要一些意见。

我打算为朋友开发一个 POS 和库存软件。这是一个单人小规模项目，所以我想让架构尽可能简单。

我正在使用 Winform 开发 GUI（Web 界面对 POS 软件没有意义）。对于数据库，我使用的是 Postgresql。

该程序将根据用户角色控制访问，因此我必须开发一个中间层，使用 Web 服务器来控制用户访问，或者我可以直接在 Postgresql 中设置用户权限。

开发中间层会很耗时，维护也会更复杂。所以我更喜欢直接在数据库中设置访问控制。

现在看来，使用数据库来控制用户访问是很麻烦的。我必须为每个角色设置权限。更不用说对于某些表，权限是列级别的。这使得对安全性的推理变得非常困难。

所以我现在正在做的是将所有表设置为除超级用户外不可访问。该程序将使用公共角色连接到数据库。由于公共无法访问这些表，因此我将使用 SECURITY DEFINER（具有超级用户角色）创建可公开访问的存储函数。访问表的唯一方法是使用这些函数。

我将把用户角色和密码放在一个表中。因为非超级用户无法访问用户表本身，所以我将创建一个登录函数，我们称之为fn_login(username, password)。如果登录成功，fn_login 将返回一个会话密钥。

要调用其他函数，我们需要为用户提供会话密钥，例如：fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...)。

这样，我将存储的函数视为 API。添加新用户会更容易，因为我只需要在用户表中添加新行而不是添加新的 Postgresql 角色。我不需要在列级别设置权限。所有控件都将以编程方式完成。

所以你怎么看？这种方法是否可行且可扩展？有更好的方法吗？

谢谢！

4

4 回答 4

2

I believe there is a better way to do it. But since you haven't discussed what type of security you need, I cannot elaborate on specifics.

Since you are developing the application code in .NET, that code needs to be trusted (unlike a web application). Therefore, why don't you simply implement your roles and permissions in the application code, rather than the database?

My concern with your stated approach is the human overhead of stored procedures. Would much rather see you write the stated functions in C#, rather than in PostgreSQL. Then, standard version control and software development techniques could apply.

于 2009-12-13T01:57:20.967 回答
1

如果您等到有人在您的数据库中检查安全性，我认为您为时已晚。这是 90 年代末出现的客户端/服务器心态。这是 n 层架构流行的部分原因。客户端/服务器不能像 n 层解决方案那样水平扩展。

我建议您更好地利用中间层。安全性应该是一个跨领域的问题，它比你的持久层更进一步。

于 2009-12-13T03:51:01.580 回答
0

如果数据库安全的管理是问题，那么您应该添加自动化该管理的任务。这意味着您可以使用数据库表存储更高级别的数据，然后您的应用程序可以将该数据转换为数据库所需的适当细节和工件。

听起来数据库有您需要的详细信息，您只需要促进该详细信息的管理，并将其滚动到您的应用程序中。

于 2009-12-13T04:21:17.060 回答
0

我诚实的建议：不要发明 POS 和库存软件。采用现有项目之一并使其变得更好。

于 2009-12-14T12:06:26.827 回答