使用Postgresql作为中间层。需要意见

时间:2009-12-13 01:05:59

标签: postgresql stored-procedures stored-functions middle-tier

我需要一些意见。

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

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

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

开发中间层将非常耗时,维护将更加复杂。所以我更喜欢直接在数据库中设置访问控制。

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

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

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

要调用其他功能,我们需要为用户提供会话密钥,例如:fn_purchase_list(session_key)fn_purchase_new(session_key, purchase_id, ...)

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

那你觉得怎么样?这种方法是否可行且可扩展?有没有更好的方法呢?

谢谢!

4 个答案:

答案 0 :(得分:2)

我相信有更好的方法。但由于您尚未讨论所需的安全类型,因此无法详细说明具体细节。

由于您在.NET中开发应用程序代码,因此需要信任该代码(与Web应用程序不同)。因此,为什么不简单地在应用程序代码中实现您的角色和权限,而不是数据库?

我对您声明的方法的关注是存储过程的人力开销。更愿意看到你用C#编写声明的函数,而不是PostgreSQL。然后,可以应用标准版本控制和软件开发技术。

答案 1 :(得分:1)

如果你等到有人在您的数据库中检查安全性,我想你会为时已晚。这是一种在90年代末出现的客户/服务器心态。这是n层架构开始流行的部分原因。客户端/服务器无法进行水平扩展以及n层解决方案。

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

答案 2 :(得分:0)

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

听起来数据库具有您需要的细节,您只需要方便管理该细节,并将其滚动到您的应用程序中。

答案 3 :(得分:0)

我诚实的建议:不要发明POS和库存软件。选择existing projects中的一个并使其更好。