系统用户
系统用户为 ThingWorx 中的系统对象，旨在简化内部服务权限的管理，同时仍可按不同的用户来设置外部 API 层的权限。系统用户是可选的。如果未将系统用户分配给某个服务，则对于最初请求所有后续包络服务的用户，ThingWorx 将检查该用户的权限。
通常情况下，当用户调用某个服务时，该用户必须对所调用的服务有访问权限，且有权从初始调用的服务调用任何其他服务。例如，用户对某个事物执行名为 GetMachineRunTimeHistory 的服务，而该事物又内部调用 QueryStreamEntriesWithData 和 GetDataTableEntryByKey。如果不使用系统用户，已调用 GetMachineRunTimeHistory 的用户还需要具有执行 QueryStreamEntriesWithData 和 GetDataTableEntryByKey 的明确权限。
对于系统用户，如果是从服务或订阅调用某个客户服务 (包络服务调用)，且允许系统用户执行该服务，则会允许执行该服务，而不管最初触发事件、脚本或服务序列的用户是谁。不过，用户不能直接调用包络服务本身 (上例中为 QueryStreamEntriesWithData 或 GetDataTableEntryByKey，除非明确允许用户可以这样做)。
这使得管理员能够使用具有显式访问权限的用户和组来锁定可从外部访问的曲面 API。从权限管理的角度来看，尽管始终建议依赖于用户传播至包络服务调用，但系统用户仍可以更轻松地管理内部服务调用。
可将系统用户添加到管理员组中。这样，可以针对服务调用中的所有内容为所有用户授予完整权限 - 在客户服务内调用的所有服务都将成功，而不管调用用户的权限为何。
 |
不建议使用系统用户来绕过安全性，或降低仔细设计与实现安全应用程序的需求。最好的做法是仅在特定情况下才会依赖系统用户，而不是将其用作用户传播实践的常规解决办法。
|
系统用户示例
授予系统用户运行服务权限，即每个用户都将被授予在自定义服务内运行该服务的权限，但并不一定具有直接调用该服务的权限。正确的使用方法：
1. 授予系统用户运行服务权限的同时限制该服务的权限，从而使得其他用户不具有运行该服务的权限。
2. 编写调用该受限服务的自定义服务，然后授予用户运行自定义服务而非受限服务的权限。
3. 即使用户不具有运行受限服务的权限，也能够运行该自定义服务。
要举例进一步说明此概念，请考虑下列使用情况：
您想要编写一个特定连接设备状态将显示给用户的自定义服务，名为 CustomService1。为此，CustomService1 会使用 DeviceFunctions 资源上的 SearchDevices 服务来查看平台上的所有设备，然后筛选出结果以返回特定的设备。
但是，该服务不仅会检查 CustomService1 权限，还会检查 CustomService1 内的每个服务调用权限。用户需要具有运行 SearchDevices 服务的权限才能成功调用 CustomService1，否则调用 CustomService1 将失败。授予用户调用 SearchDevices 的权限并非理想解决方案，原因在于您可能不希望用户有权访问每个设备的状态，而是仅限其访问特定的设备。
系统用户可以解决此问题。当直接执行服务时，系统将检查该用户的权限以确定其是否具有权限。这适用于所有服务 (包括所有自定义服务)。但是，当从自定义服务中执行服务时，系统实际上会检查两个权限：用户权限和系统用户的权限。如果用户或系统用户有权运行自定义服务中的服务，则内部服务将如同用户有权运行该服务一样执行。由于 SearchDevices 仅在 CustomService1 内部调用并且不会直接调用，您可以授予系统用户运行 SearchDevices 的权限。当用户调用 CustomService1 时，系统会进行权限检查，从而发现 User1 不具有权限，但同时也发现该系统用户具有权限。因此，SearchDevices 将如同用户具有权限一样执行。如果用户曾经尝试直接调用 SearchDevices，而未从 CustomService1 内部调用，则系统用户权限不可用，并且用户的权限将被拒绝。
