Hibernate 如何防止用户修改他们不拥有的资源？

我正在编写一个服务器，其中我有一个实体

StoreOwner

，该实体“拥有”或与

商店

实体有

@OneToMany

关系（一个商店所有者拥有1到N个商店）。每个

商店

都有

优惠

和

商品

，每个商店还与商店有

@OneToMany

关系（一个商店有1到N个优惠和1到N个商品）

我已经在使用GWT Xsrf保护和一个会话ID，该ID在每次登录（cookie）后与登录用户关联

关于会话ID的一件事：在用户“识别”自己并输入用户名和密码后，会话ID会被放入我的数据库中。无论用户是否被黑客攻击、丢失了hist笔记本电脑或正确输入了凭据：用户都将被视为已登录我的服务器-它如何知道？但是

IMHO缺少一件事：如果登录（验证）用户向服务器发送一个删除请求，请求中包含他也不拥有的商店中他不拥有的项目ID，该怎么办？目前，我正在我的

商店服务中执行此操作

：

// StoreService.java

@Transactional
public ItemDTO deleteItem(String sessionId, Long storeId, ItemDTO itemDto) {

    // sessionId is the cookie I have placed in my database
    // This way I want to ensure that I am only accessing a store
    // that is associated with the logged in store owner (the user basically)
    Store store = this.storeOwnerRepository.getStore(sessionId, storeId);

    Item item = ConvertDTO.convertItem(store, itemDto);

    // Check if the store ID that I got using the cookie is the
    // same ID as the store ID from the item that should be deleted
    if(item .getStore().getId() == store.getId()) {
        item = this.storeOwnerRepository.deleteItem(item);
    } else {
        // If this didn't work we have a potentially hostile user:
        throw new RuntimeException("Is somebody trying to delete items of a store he doesn't own?");
    }

    itemDto = ConvertEntity.convertItem(item);
    return itemDto;
}

这是我第一次尝试编写一个更大的服务器应用程序，我想阻止用户做这样的事情

我的问题有两个：[1]我所做的是否真的可以防止登录用户将他不拥有的另一个商店的ID走私到我的服务器？另外，[2]我能简化一下吗

我的问题是，随着应用程序的增长，人们可能会偶尔忘记这个检查

if(item .getStore().getId() == store.getId()) { /* .. */ }

当然，我可以将其移动到我的

店主存储库中，但我有更好的选择吗？
。任何了解您的数据的用户都可以使用上述方法删除资源，特别是当该方法作为端点通过web公开时。除非有某种形式的验证机制，否则传递和使用会话ID是非常困难的

在不了解更多关于应用程序架构的信息的情况下，我只能回答这个问题

作为一个恶意用户，我会问：“我需要做什么来造成损害？”

会话ID
商店ID
项目的结构
如何将上述所有信息发送到后端（XML、JSON等）
知道这些信息后，使用诸如或之类的应用程序，我可以向您的后端发送虚假请求

那么，问题是，上面哪一项很容易发现，复制起来又有多容易？答案是：可能没那么难。换句话说，您的实现（如上所述）并不会阻止用户执行我刚才提到的操作（同样，对您的应用程序不太了解）

Hibernate本身不是一种提供安全性的机制——它的唯一责任是ORM。您可以考虑查看——这样可以更好地实现更可扩展的安全措施。
根据您可以访问的信息，您需要确定一种方法，以最好地防止用户伪造他们的身份。会话ID似乎是可伪造的
 用户可以与定义其权限的持久化授权对象关联。此外，开放供修改的对象可以具有与其关联的权限对象（与实体一起存储）。用户的授权凭证可以从持久性层抓取，并与存储库中实体的授权凭证进行比较。通过这样做，用户无法通过将“坏”JSON等传递到删除端点来“欺骗”存储库，使其相信自己拥有正确的权限。@Thomas我不确定这在这里的例子中是什么意思。与StoreOwner的关联Cookie是否足够？这样我就可以做一些类似于
session.delete（storeOwner.getItem（itemId））。这就足够了吗？我想Spring Security就是我想要的——尤其是访问控制：）