交易执行身份为系统管理员？多用户模式REST服务器权限异常问询

问题1：交易函数中执行的身份是否为系统管理员？ #

不一定。正常情况下，交易函数的执行身份完全取决于你发起交易时使用的业务卡片对应的身份：

• 如果你用普通参与者的卡片发起交易，执行身份就是该参与者，权限校验也会基于这个参与者的ACL规则来执行；
• 只有当你使用NetworkAdmin身份的卡片发起交易时，执行身份才会是系统管理员，此时拥有所有资源的操作权限。

但如果出现问题2里的异常情况，执行身份会被强制替换为系统管理员，这是配置错误导致的。

问题2：多用户模式下权限校验失效，交易执行身份为NetworkAdmin #

这个问题的核心原因是你启动REST服务器时使用了NetworkAdmin的卡片，并且服务器默认用这个启动身份来执行所有用户的交易，完全忽略了用户自己的参与者身份权限。

具体分析： #

当你用composer-rest-server -c admin@your-network（这里的admin是NetworkAdmin）启动服务器时，哪怕你开启了多用户模式（-m true），服务器也会把所有用户发起的交易都用启动时的NetworkAdmin身份去执行——而NetworkAdmin是系统级管理员，天然拥有所有资源的操作权限，所以那个原本没有资源A权限的参与者才能成功更新资源，交易详情里的participantInvoking也会显示为resource:org.hyperledger.composer.system.NetworkAdmin#admin。

解决步骤： #

1. 正确启动REST服务器：
   开启多用户模式时，要确保服务器使用用户自身的身份执行交易，正确的启动命令示例：

   composer-rest-server -c admin@your-network -m true -n never -w true
   

   其中：

   • -m true：强制开启多用户模式；
   • -n never：禁用命名空间（可选，根据你的业务网络调整）；
   • -w true：启用WebSocket实时更新（可选）。
     关键是启动后，服务器会要求用户登录自己的业务卡片，交易执行身份会切换为用户登录的参与者身份。

2. 验证ACL规则：
   检查你的业务网络定义中的ACL文件（permissions.acl），确保你确实给目标参与者配置了禁止操作资源A的规则，比如类似这样的配置：

   rule DenyUpdateResourceA {
       description: "Deny non-admin users updating ResourceA"
       participant: "org.yourdomain.YourParticipant"
       operation: UPDATE
       resource: "org.yourdomain.ResourceA"
       action: DENY
   }
   

3. 确保用户使用正确卡片登录：
   用户必须使用自己的参与者业务卡片登录REST服务器，而不是NetworkAdmin的卡片，这样服务器才会用该参与者的身份触发权限校验。

内容的提问来源于stack exchange，提问作者T_murder