8.8. 条件流中的条件
如 执行要求 所述,Condition 执行只能包含在 Conditional 子流中。如果所有 Condition 执行都评估为 true,则条件 子流充当 Required。您可以在 条件 子流中处理下一次执行。如果 Conditional sub-flow 评估为 false 中包含某些执行,则整个子流被视为 Disabled。
8.8.1. 可用条件
condition - 用户角色
此执行能够确定该用户是否具有由 User role 字段定义的角色。如果用户具有所需的角色,则执行被视为 true,其他执行会被评估。管理员必须定义以下字段:
- Alias
- 描述执行的名称,它将显示在验证流中。
- 用户角色
-
用户应当必须要执行这个流的角色。要指定应用角色,其语法为
appname.approle
(例如myapp.myrole
)。
condition - 用户配置
- 这会检查是否为用户配置了流中的其他执行。Execution requirements 部分包括 OTP 表单的示例。
condition - 用户属性
这将检查用户是否已设置 required 属性。可能存在相关的输出,这意味着用户不应具有 属性。User Attributes 部分演示了如何添加自定义属性。您可以提供这些字段:
- Alias
- 描述执行的名称,它将显示在验证流中。
- 属性名称
- 要检查的属性的名称。
- 预期属性值
- 属性中的预期值。
- negate 输出
- 您可以设置输出。换句话说,属性不应存在。
8.8.2. 在条件流中明确拒绝/允许访问
您可以允许或拒绝访问条件流中的资源。两个验证器 拒绝访问
,并允许
根据条件对资源进行访问。
允许访问
- 验证器始终将成功进行身份验证。这个验证器不可配置。
拒绝访问
访问将始终被拒绝。您可以定义错误消息,它将向用户显示。您可以提供这些字段:
- Alias
- 描述执行的名称,它将显示在验证流中。
- 错误消息
-
将向用户显示的错误消息。错误消息可以作为特定消息或属性提供,以便将其用于本地化。(例如 "您没有角色". "admin'.", my-property-deny in messages 属性中)将默认消息留空来用作属性
access-denied
。
以下示例说明了如何拒绝对没有角色 role1
的所有用户访问,并显示由属性 deny-role1
定义的错误消息。这个示例包括 Condition - User Role
和 Deny Access
executions。
浏览器流
condition - 用户角色配置
Deny Access
的配置非常容易。您可以指定任意 Alias 和必需信息,如下所示:
最后一件事是在 login theme messages_en.properties
(对于英语)中用错误消息定义属性:
deny-role1 = You do not have required role!
deny-role1 = You do not have required role!