NHIbernate 和安全/业务层

发布于 2024-07-16 17:08:22 字数 1348 浏览 6 评论 0原文

我刚刚开始在个人项目中使用/学习 NHibernate,感觉我没有“得到”一些东西。 我习惯了应用程序像这样工作:

表示层 --> 业务层--> 持久层。 例如,我的表示层将调用 BusinessLayer.GetCustomer(id)。 在该方法中,我将检查调用者是否有权获取客户。 好的,这在 NHibernate 中仍然可以正常工作。 但我的问题是如何确保更新、添加和删除的安全性? 例如,假设我想修改我找回的客户。 通常,我会这样做:

customer.FirstName ="Mike";
BusinessLayer.UpdateCustomer(customer);

再次,UpdateCustomer 方法将检查您是否可以更新该客户。 好的,但是对于 NHibernate,要更新客户,我只需设置 FirstName。 然后我不需要调用更新,因为它是透明的。 这就是 Hibernate 的要点:“透明且自动的持久性”。 那么,如何在这种透明度下进行安全检查呢? 我只是不够相信自己不会犯错误,不会做类似的事情:

List<string> customerNames = new List<string>();
foreach (Customer c in GetCustomersThatLikeStuffThatILike()) {
   string custName="";
   c.CustomerName = custname; //Oops. I meant to say: custname = c.CustomerName;
   customerNames.Add(custName);  
}

哎呀。 我刚刚删除了数据库中所有客户的姓名。 这是做作的吗? 是的。 现在,如果我进行了某种 BusinessLayer 检查,这只会引发异常,因为该用户无法更新其他用户的名称。

另一个问题。 假设我是管理员,确实可以在系统中执行任何操作,并且我有这样的代码:

//Display a customers orders that haven't shipped yet:
var Orders = Customer.Orders;
Orders.RemoveAll(order => order.HasNotShipped);
Grid.DataSource = Orders;
Grid.DataBind();

好的,所以在这里我只想过滤订单,但我不小心最终从数据库中删除了它们。 透明度导致我做了一些非常糟糕的事情。 如何降低这一风险?

我真的使用NHibernate,但我不想想以错误的方式去做。 帮助! :)

I'm just starting to play around with / learn NHibernate for a personal project, and feel like I'm not "getting" something. I'm used to having apps work like this:

Presentation layer --> Business Layer --> Persistence layer. So for example, my presentation layer would call BusinessLayer.GetCustomer(id). In that method I would check that the caller has the right to fetch the customer. OK, that still works just fine with NHibernate. My question though is how do I have any security on Updates, Adding, and Deletes? For example, Suppose I want to modify the customer I got back. Normally, I would have done this:

customer.FirstName ="Mike";
BusinessLayer.UpdateCustomer(customer);

Again, the UpdateCustomer method would check that you can update this customer. OK, but with NHibernate, to update the customer I'm simply going to set the FirstName. I then don't NEED to call Update since it's all transparent. That's the point of Hibernate right: "Transparent and Automated Persistence." So how do I have my security checks in place with this transparency? I simply don't trust myself enough to not make a mistake and do something like:

List<string> customerNames = new List<string>();
foreach (Customer c in GetCustomersThatLikeStuffThatILike()) {
   string custName="";
   c.CustomerName = custname; //Oops. I meant to say: custname = c.CustomerName;
   customerNames.Add(custName);  
}

Oops. I just wiped out all the customers' names in the database. Is this contrived? Yes. Now, if I had some sort of BusinessLayer check in place, this would just throw an exception because that user can't update other users' names.

Another issue. Suppose I'm an admin and can really do anything in the system and I have code like this:

//Display a customers orders that haven't shipped yet:
var Orders = Customer.Orders;
Orders.RemoveAll(order => order.HasNotShipped);
Grid.DataSource = Orders;
Grid.DataBind();

OK, so here I just wanted to filter the orders, but I accidentally ended up deleting them from the database. The transparency caused me to do something very bad. How does one mitigate that risk?

I really want to use NHibernate but I don't want to do it the wrong way. Help! :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

烟凡古楼 2024-07-23 17:08:22

对于您的安全问题,请查看 NHibernate Inteceptor文档。 拦截器让您能够进入会话生命周期,并启用您正在寻找的功能。

第二个问题是为什么您创建存储库并仅公开您需要的功能。 如果应用程序不需要RemoveAll函数(大多数都不需要),那么就不要公开它。

For your security question, look at the NHibernate Inteceptor documentation. Interceptors let you hook into the session lifecycle and will enable the functionality you are looking for.

The second issue is why you create repositories and expose only the functionality you need. If an application doesn't need the RemoveAll function (and most don't), then don't expose it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文