后端认证鉴权单点登录身份认证【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载本篇技术指南聚焦 Apereo CAS 中 Spring Webflow 的扩展与定制讲解如何在不改动 CAS 核心代码的前提下通过 Java 自动配置组件与 Groovy 脚本两种途径向login、logout、pswdreset、account四大核心流程动态注入自定义 Action、State 与 Transition。读者完成阅读后将掌握AbstractCasWebflowConfigurer的 DSL 式编程模型、CasWebflowExecutionPlan的注册机制以及cas.webflow.groovy.*系列配置属性的实战用法并能在自己的 CAS Overlay 中直接落地这些方案。认识 CAS 的核心 Webflow 结构Spring Webflow 是 CAS 组织认证流程的底层引擎。CAS 本身并不试图重新发明流程编排而是围绕 Spring Webflow 的 Action、State、Transition、Scope 等概念搭建了一套自己的门面Facade与自动装配体系。本指南的重点是如何扩展 CAS 的 Webflow而不是讲解 Spring Webflow 的内部机制如需学习后者可参考 Spring Webflow 官方项目。CAS 默认依赖以下四个核心 Webflow 配置文件Flow说明login登录认证流程负责处理登录尝试logout登出认证流程负责处理登出尝试pswdreset密码管理密码管理指南与密码重置流程account账户管理账户管理概览与个人资料流程需要特别强调的是上面这些流程只是 CAS 核心所需的最小骨架。在运行时大量其他 Action 和 State 会根据 CAS 配置和功能模块的启停情况被动态注入到上述流程中每个功能模块自身也可能携带专属的、有倾向性的子流程subflow配置文件这些子流程会在运行时被自动发现并加载。这一点可以从 CasWebflowConfigurer 接口中定义的流程 ID 常量得到印证——除了FLOW_ID_LOGIN login、FLOW_ID_LOGOUT logout、FLOW_ID_PASSWORD_RESET pswdreset、FLOW_ID_ACCOUNT account还存在FLOW_ID_RISK_VERIFICATION riskauthverify、FLOW_ID_DELEGATION_REDIRECT clientredirect等由具体功能模块动态注册的流程。修改 Webflow 的两条路线与取舍路线一直接覆盖流程配置文件仅限简单场景在最简单的场景下你可以通过 WAR Overlay 安装方式 覆盖核心流程配置文件从而增加或覆写所需行为。但请务必谨慎尽量避免对 Webflow 做临时性的临时改动。在动手之前先思考你想要的变更是否更适合作为补丁直接提交给 CAS 项目本身——这样你只需享受配置带来的能力而无需承担其长期维护成本。路线二使用 CAS API 编程扩展高级场景当你需要深入并根据条件动态改变 CAS 核心行为时应当使用 CAS API。直接使用 CAS API 有以下优势同时也伴随着一定的成本所有变更都被限定在 Java也可以是 Groovy、Kotlin、Clojure 等 JVM 语言范围内你可以利用 Java 的全部能力动态地、有条件地增强 Spring Webflow你的改动完全自包含self-contained改动已经成为 CAS API 的一部分并且会被编译。升级时若有破坏性变更通常在构建期就能立刻发现。下面分别介绍 Java 与 Groovy 两种具体实现方式。方式一Java 自动配置组件最传统也最强大这种方式的本质是编写一个能够自动装配auto-configureWebflow 的组件让它注入到正在运行的 CAS 应用上下文中并在运行时被消费执行。最低限度你的 Overlay 需要引入cas-server-core-webflow模块Grouporg.apereo.cas。设计继承 AbstractCasWebflowConfigurer设计你的动态 Webflow 配置代理agent形式如下public class MyWebflowConfigurer extends AbstractCasWebflowConfigurer { public MyWebflowConfigurer(FlowBuilderServices flowBuilderServices, FlowDefinitionRegistry flowDefinitionRegistry, ApplicationContext applicationContext, CasConfigurationProperties casProperties) { super(flowBuilderServices, flowDefinitionRegistry, applicationContext, casProperties); } Override protected void doInitialize() throws Exception { var flow super.getLoginFlow(); // 调用 super 查看可用的辅助方法然后按需改造 flow。 } }父类 AbstractCasWebflowConfigurer 提供了大量 DSL 风格的辅助方法与工具用于隐藏 Spring Webflow API 的复杂性让定制更加容易。从源码看它至少提供了以下几类能力流程获取getLoginFlow()、getLogoutFlow()直接返回对应Flow对象见 AbstractCasWebflowConfigurer.java#L140-L148状态创建createActionState(...)、createDecisionState(...)、createViewState(...)、createEndState(...)、createSubflowState(...)以及createEndViewState(...)等覆盖了 Spring Webflow 几乎全部状态类型转移Transition创建createTransition(...)系列方法支持以字符串结果名或 SpEL 表达式作为条件并可携带执行动作createTransitionForState(...)、createStateDefaultTransition(...)、insertTransitionForState(...)用于为已有状态挂接或插入转移动作与表达式createEvaluateAction(expression)基于flowBuilderServices的表达式解析器把字符串编译为EvaluateAction见 AbstractCasWebflowConfigurer.java#L229-L240createRenderAction(...)、createSetAction(...)分别对应渲染与赋值动作查询与判断containsFlowState(flow, stateId)、containsTransition(state, transition)、getState(flow, stateId, clazz)、getTransitionableState(...)用于安全地探测和获取流程元素避免空指针与重复创建模型绑定与子流程createStateModelBinding(...)、createStateBinderConfiguration(...)、createFlowInputMapper(...)、createSubflowAttributeMapper(...)用于视图模型绑定与父子流程间的数据映射克隆与重排cloneActionState(...)、createClonedActionState(...)、prependActionsToActionStateExecutionList(...)、addActionsToActionStateExecutionListAt(...)可复制既有状态或在执行列表中按位置插入动作。值得一提的是initialize()方法会先检查casProperties.getWebflow().getAutoConfiguration().isEnabled()只有自动配置开启时才会调用doInitialize()否则仅记录一条日志见 AbstractCasWebflowConfigurer.java#L128-L138。这与你稍后看到的cas.webflow.autoconfigure.enabled配置项直接对应。注册接入 CAS 应用运行时设计完成后需要把组件注册进 CAS 应用运行时package org.example; AutoConfiguration EnableConfigurationProperties(CasConfigurationProperties.class) public class MyAutoConfiguration { Bean public CasWebflowConfigurer myWebflowConfigurer( CasConfigurationProperties casProperties, Qualifier(CasWebflowConstants.BEAN_NAME_FLOW_DEFINITION_REGISTRY) FlowDefinitionRegistry flowDefinitionRegistry, ApplicationContext applicationContext, FlowBuilderServices flowBuilderServices) { return new MyWebflowConfigurer(flowBuilderServices, flowDefinitionRegistry, applicationContext, casProperties); } Bean public CasWebflowExecutionPlanConfigurer myWebflowPlanConfigurer( Qualifier(myWebflowConfigurer) CasWebflowConfigurer myWebflowConfigurer) { return plan - plan.registerWebflowConfigurer(myWebflowConfigurer); } }这里的几个关键点需要展开说明CasWebflowConstants.BEAN_NAME_FLOW_DEFINITION_REGISTRY的实际值是flowDefinitionRegistry对应的 Bean 名常量定义在 CasWebflowConstants同一份常量接口里还集中定义了数以百计的状态 ID 与动作 Bean 名例如STATE_ID_INIT_LOGIN_FORM initializeLoginForm、STATE_ID_VIEW_LOGIN_FORM viewLoginForm、STATE_ID_REAL_SUBMIT realSubmit、STATE_ID_SUCCESS success等编写配置器时建议直接引用这些常量而不是手写字符串。CasWebflowExecutionPlanConfigurer是一个函数式接口plan.registerWebflowConfigurer(...)会把你的配置器纳入 CasWebflowExecutionPlan 的统一执行计划。CAS 自身也正是这样做的在 CasWebflowContextConfiguration 中casDefaultWebflowExecutionPlanConfigurer依次注册了defaultWebflowConfigurer、defaultLogoutWebflowConfigurer与可选的groovyWebflowConfigurer并注册了 locale、resource、theme 等 Webflow 拦截器——你的自定义配置器会与这些内置配置器在同一计划中按Order顺序协同执行。配置类需要按照 配置管理扩展策略 注册到 CAS 中才能被自动装配机制发现。此外CAS 内置的groovyWebflowConfigurerBean 在 GraalVM 原生镜像Native Image下会被ConditionalOnMissingGraalVMNativeImage条件排除见 CasWebflowContextConfiguration.java#L299-L311因此在原生镜像环境中请优先考虑纯 Java 的扩展方式。关于编译的提示编译配置类以及放入 CAS Overlay 的任何其他 Java 代码可能需要额外的 CAS 模块与依赖位于 classpath 上。你需要研究 CAS 代码库找到包含所需组件例如CasWebflowConfigurer的正确模块。CasWebflowConfigurer及其配套接口定义在cas-server-core-api-webflow模块中而AbstractCasWebflowConfigurer的完整实现位于cas-server-core-webflow-api。方式二Groovy 脚本轻量但需谨慎如果你希望用更轻量的方式让 CAS 在运行时自动配置、改造 Webflow可以通过 Groovy 脚本实现。这种方式对 CAS API 的访问相对有限但 Overlay 的配置与依赖搭建更简单因为一切均由 CAS 在运行时提供。⚠️停止编码先想清楚这里提供的 API尤其作为 Groovy 脚本一部分执行的 API在很大程度上被视为 CAS 的内部实现。它们可能随时被添加或移除这意味着变更可能在运行时破坏你的部署与升级。与 Java 类不同脚本在构建 CAS 时不会被静态编译你可能只有在真正启动服务器部署时才会观察到失败。因此选择这个选项要有充分的理由并在编码前深思熟虑。配置启用 Groovy 支持要让 CAS 支持并集成 Apache Groovy请先阅读 Apache Groovy 脚本集成指南。之后通过以下配置属性启用 Webflow 自动配置配置项说明cas.webflow.autoconfigure.enabled是否启用 Webflow 自动配置默认true对应 WebflowAutoConfigurationProperties 中的enabled字段cas.webflow.groovy.locationGroovy 脚本的资源路径用于自动配置 Webflow 上下文动态创建/移除状态与动作对应 GroovyWebflowProperties 继承自SpringResourceProperties的location字段cas.webflow.groovy.actions.beanName以 Map 形式为指定 Webflow Action 的 Bean 名提供 Groovy 替代实现脚本路径这些属性的底层实现位于 WebflowProperties其中groovy嵌套属性明确注释为路径到可自动配置 Webflow 上下文的 Groovy 资源可动态创建/移除状态与动作。Webflow 自动配置脚本下面是一个示例 Groovy 脚本它定位 CAS 登录流程中预定义的一个状态如果找到就向该状态插入一个自定义动作使其在 CAS 进入该状态时立即执行。虽然这是一个相当朴素的例子但请注意该脚本有能力增删动作、状态、转移增删子流程等。import java.util.* import org.apereo.cas.* import org.apereo.cas.web.* import org.apereo.cas.web.support.* import org.apereo.cas.web.flow.* import org.springframework.webflow.* import org.springframework.webflow.engine.* import org.springframework.webflow.execution.* Object run(final Object... args) { def (webflow,springApplicationContext,logger) args logger.info(Configuring webflow context...) def loginFlow webflow.getLoginFlow() if (webflow.containsFlowState(loginFlow, CasWebflowConstants.STATE_ID_INIT_LOGIN_FORM)) { logger.info(Found state that initializes the login form) def state webflow.getState(loginFlow, CasWebflowConstants.STATE_ID_INIT_LOGIN_FORM, ActionState.class) logger.info(The state id is {}, state.id) state.getEntryActionList().add({ requestContext - def flowScope requestContext.flowScope def httpRequest WebUtils.getHttpServletRequestFromExternalWebflowContext(requestContext) logger.info(Action executing as part of ${state.id}. Stuff happens...) return new Event(this, success) }) logger.info(Added action to ${state.id}s entry action list) } return true }脚本接收的参数如下参数说明webflow一个门面对象封装了对 Spring Webflow API 的访问。它本身就是一个CasWebflowConfigurer在GroovyWebflowConfigurer.doInitialize()中CAS 把this作为第一个参数传入见 GroovyWebflowConfigurer.java#L28-L40因此getLoginFlow()、containsFlowState()、getState()等方法都可用springApplicationContextSpring 应用上下文logger日志对象用于输出如logger.info(...)之类的日志消息仓库中的测试用例 GroovyWebflowConfigurerTests 直接验证了这一机制它通过TestPropertySource(properties cas.webflow.groovy.locationclasspath:/GroovyWebflow.groovy)指向测试脚本并断言groovyWebflowConfigurer.initialize()不抛异常。Webflow Action 的 Groovy 替代实现Webflow 操作通常由实现了Action接口、并以Bean定义形式注册到 CAS 运行时的组件处理。虽然这些 Bean 定义可以被其他实现有条件地替换你也可以选择通过 Groovy 脚本接管动作实现本身——此时动作的实现责任完全转移到你手中CAS 不再为你提供实现。注意在提供 Groovy 替代实现之前你需要先仔细分析 CAS 代码库挖掘出原始动作Bean的名字。另外请注意并非所有 Spring Webflow 动作都能用 Groovy 等价替换。Groovy 在这一领域的支持是一个持续演进的过程会在各 CAS 版本中逐步完善请务必对照代码库确认。脚本的大致框架如下import org.apereo.cas.authentication.principal.* import org.apereo.cas.authentication.* import org.apereo.cas.util.* import org.springframework.webflow.* import org.springframework.webflow.action.* def run(Object[] args) { def (requestContext,applicationContext,properties,logger) args logger.info(Handling action...) return new EventFactorySupport().event(this, success) }脚本的返回值必须是 Spring Webflow 的Event对象。传入参数如下参数说明requestContext代表 Spring Webflow 执行上下文的对象携带 HTTP 请求与响应applicationContextSpring 应用上下文properties对 CAS 配置属性的引用即CasConfigurationPropertieslogger日志对象用于输出如logger.info(...)之类的日志消息从源码层面看这一机制由 GroovyScriptWebflowAction 实现它以{requestContext, applicationContext, casProperties, LOGGER}四个参数调用脚本并要求脚本返回Event类型。而 WebflowActionBeanSupplier 则负责条件装配——只有当cas.webflow.groovy.actions中存在对应 Bean 名的条目时才会用GroovyScriptWebflowAction替换原有的默认动作实现否则回落fallback到默认实现。这与 GroovyWebflowProperties 中关于key 为提供 Webflow 动作的 Bean 名/标识符、value 为 Groovy 脚本资源路径如file:/path/to/Script.groovy的注释完全吻合。仓库中同样带有可直接参考的测试资源 GroovyWebflowAction.groovy以及对应测试 GroovyScriptWebflowActionTests测试断言脚本执行后返回的EventID 与脚本内构造的result一致。从常量与源码看 CAS Webflow 的可扩展设计要写出健壮的扩展代码建议把 CasWebflowConstants 当作你的字典。这份接口文件长达数千行集中了Bean 名如BEAN_NAME_FLOW_DEFINITION_REGISTRY flowDefinitionRegistry、BEAN_NAME_FLOW_BUILDER_SERVICES flowBuilderServices状态 ID如STATE_ID_INIT_LOGIN_FORM、STATE_ID_VIEW_LOGIN_FORM、STATE_ID_REAL_SUBMIT、STATE_ID_SUCCESS、STATE_ID_LOGOUT_VIEW、STATE_ID_FINISH_LOGOUT等转移 ID 与动作 Bean 名如TRANSITION_ID_SUCCESS success、ACTION_ID_INIT_LOGIN_ACTION initializeLoginAction、ACTION_ID_AUTHENTICATION_VIA_FORM_ACTION authenticationViaFormAction、ACTION_ID_FETCH_TICKET_GRANTING_TICKET fetchTicketGrantingTicketAction等。在 Java 与 Groovy 两种方式中直接引用这些常量可以显著降低拼写错误与升级断链的风险。从整体设计来看CAS 的 Webflow 扩展遵循计划Plan 配置器Configurer的架构所有CasWebflowConfigurer通过CasWebflowExecutionPlanConfigurer注册进 CasWebflowExecutionPlan最终由execute()统一驱动初始化而AbstractCasWebflowConfigurer.initialize()中的cas.webflow.autoconfigure.enabled开关为整套机制提供了总闸。理解这条调用链后无论采用 Java 还是 Groovy你都能精确判断自己的扩展代码将在什么时机、以什么顺序生效。总结选型建议维度Java 自动配置组件Groovy 脚本能力上限完全访问 Spring Webflow API 与 CAS 辅助方法通过门面对象获得有限但够用的访问能力构建期安全编译期即可发现破坏性变更运行时才可能暴露问题配置成本需要额外依赖与模块研究Overlay 配置简单CAS 运行时提供一切升级风险较低随 CAS API 编译较高API 被视为内部实现可能随时变动适用场景复杂的、条件化的核心行为改造轻量的状态/动作插入与实验性改造对希望深度定制登录、登出等核心流程的团队Java 方案是最稳妥的长期选择对快速验证想法或做小范围调整的场景Groovy 脚本能显著降低门槛。无论选择哪种方式都请记住文档中的核心建议优先考虑把有价值的改动回馈给 CAS 项目本身避免在 Overlay 中维护一份永远要手动同步的私有补丁。如果发现 Webflow 自动配置策略未能按预期工作请在社区中提出讨论并提交修正缺陷或添加所需行为的补丁让改动落在它真正该在的地方。赞分享后端认证鉴权单点登录身份认证【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Bootstrap Icons 中的 Diamond fill 图标SVG 源码、码点与实战用法详解Bootstrap Icons 中的 Diamond fill 图标SVG 源码、码点与实战用法详解 导读 本文以 Bootstrap Icons 开源图标库后端认证鉴权单点登录身份认证Apereo CAS Webflow 自定义装饰器用 Groovy 脚本为登录页注入动态数据Apereo CAS Webflow 自定义装饰器用 Groovy 脚本为登录页注入动态数据 本指南围绕 Apereo CAS 的 Groovy 登录装饰器后端认证鉴权单点登录身份认证Apereo CAS 自定义认证中断Custom Authentication Interrupt基于 InterruptInquirer 扩展登录流程Apereo CAS 自定义认证中断Custom Authentication Interrupt基于 InterruptInquirer 扩展登录流程后端认证鉴权单点登录身份认证上一篇使用 OHCI-1394 火线控制器物理 DMA 进行 Linux 内核调试从早期启动日志抓取到全内存转储下一篇dbt CoreRust 版贡献开发指南从环境搭建、代码质量门禁到 CHANGELOG 全流程解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/16 2:53:30 · 阅读 1.2k Apereo CAS Webflow 扩展定制完全指南：基于 Java 与 Groovy 动态改造登录流程
后端认证鉴权单点登录身份认证【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载本篇技术指南聚焦 Apereo CAS 中 Spring Webflow 的扩展与定制讲解如何在不改动 CAS 核心代码的前提下通过 Java 自动配置组件与 Groovy 脚本两种途径向login、logout、pswdreset、account四大核心流程动态注入自定义 Action、State 与 Transition。读者完成阅读后将掌握AbstractCasWebflowConfigurer的 DSL 式编程模型、CasWebflowExecutionPlan的注册机制以及cas.webflow.groovy.*系列配置属性的实战用法并能在自己的 CAS Overlay 中直接落地这些方案。认识 CAS 的核心 Webflow 结构Spring Webflow 是 CAS 组织认证流程的底层引擎。CAS 本身并不试图重新发明流程编排而是围绕 Spring Webflow 的 Action、State、Transition、Scope 等概念搭建了一套自己的门面Facade与自动装配体系。本指南的重点是如何扩展 CAS 的 Webflow而不是讲解 Spring Webflow 的内部机制如需学习后者可参考 Spring Webflow 官方项目。CAS 默认依赖以下四个核心 Webflow 配置文件Flow说明login登录认证流程负责处理登录尝试logout登出认证流程负责处理登出尝试pswdreset密码管理密码管理指南与密码重置流程account账户管理账户管理概览与个人资料流程需要特别强调的是上面这些流程只是 CAS 核心所需的最小骨架。在运行时大量其他 Action 和 State 会根据 CAS 配置和功能模块的启停情况被动态注入到上述流程中每个功能模块自身也可能携带专属的、有倾向性的子流程subflow配置文件这些子流程会在运行时被自动发现并加载。这一点可以从 CasWebflowConfigurer 接口中定义的流程 ID 常量得到印证——除了FLOW_ID_LOGIN login、FLOW_ID_LOGOUT logout、FLOW_ID_PASSWORD_RESET pswdreset、FLOW_ID_ACCOUNT account还存在FLOW_ID_RISK_VERIFICATION riskauthverify、FLOW_ID_DELEGATION_REDIRECT clientredirect等由具体功能模块动态注册的流程。修改 Webflow 的两条路线与取舍路线一直接覆盖流程配置文件仅限简单场景在最简单的场景下你可以通过 WAR Overlay 安装方式 覆盖核心流程配置文件从而增加或覆写所需行为。但请务必谨慎尽量避免对 Webflow 做临时性的临时改动。在动手之前先思考你想要的变更是否更适合作为补丁直接提交给 CAS 项目本身——这样你只需享受配置带来的能力而无需承担其长期维护成本。路线二使用 CAS API 编程扩展高级场景当你需要深入并根据条件动态改变 CAS 核心行为时应当使用 CAS API。直接使用 CAS API 有以下优势同时也伴随着一定的成本所有变更都被限定在 Java也可以是 Groovy、Kotlin、Clojure 等 JVM 语言范围内你可以利用 Java 的全部能力动态地、有条件地增强 Spring Webflow你的改动完全自包含self-contained改动已经成为 CAS API 的一部分并且会被编译。升级时若有破坏性变更通常在构建期就能立刻发现。下面分别介绍 Java 与 Groovy 两种具体实现方式。方式一Java 自动配置组件最传统也最强大这种方式的本质是编写一个能够自动装配auto-configureWebflow 的组件让它注入到正在运行的 CAS 应用上下文中并在运行时被消费执行。最低限度你的 Overlay 需要引入cas-server-core-webflow模块Grouporg.apereo.cas。设计继承 AbstractCasWebflowConfigurer设计你的动态 Webflow 配置代理agent形式如下public class MyWebflowConfigurer extends AbstractCasWebflowConfigurer { public MyWebflowConfigurer(FlowBuilderServices flowBuilderServices, FlowDefinitionRegistry flowDefinitionRegistry, ApplicationContext applicationContext, CasConfigurationProperties casProperties) { super(flowBuilderServices, flowDefinitionRegistry, applicationContext, casProperties); } Override protected void doInitialize() throws Exception { var flow super.getLoginFlow(); // 调用 super 查看可用的辅助方法然后按需改造 flow。 } }父类 AbstractCasWebflowConfigurer 提供了大量 DSL 风格的辅助方法与工具用于隐藏 Spring Webflow API 的复杂性让定制更加容易。从源码看它至少提供了以下几类能力流程获取getLoginFlow()、getLogoutFlow()直接返回对应Flow对象见 AbstractCasWebflowConfigurer.java#L140-L148状态创建createActionState(...)、createDecisionState(...)、createViewState(...)、createEndState(...)、createSubflowState(...)以及createEndViewState(...)等覆盖了 Spring Webflow 几乎全部状态类型转移Transition创建createTransition(...)系列方法支持以字符串结果名或 SpEL 表达式作为条件并可携带执行动作createTransitionForState(...)、createStateDefaultTransition(...)、insertTransitionForState(...)用于为已有状态挂接或插入转移动作与表达式createEvaluateAction(expression)基于flowBuilderServices的表达式解析器把字符串编译为EvaluateAction见 AbstractCasWebflowConfigurer.java#L229-L240createRenderAction(...)、createSetAction(...)分别对应渲染与赋值动作查询与判断containsFlowState(flow, stateId)、containsTransition(state, transition)、getState(flow, stateId, clazz)、getTransitionableState(...)用于安全地探测和获取流程元素避免空指针与重复创建模型绑定与子流程createStateModelBinding(...)、createStateBinderConfiguration(...)、createFlowInputMapper(...)、createSubflowAttributeMapper(...)用于视图模型绑定与父子流程间的数据映射克隆与重排cloneActionState(...)、createClonedActionState(...)、prependActionsToActionStateExecutionList(...)、addActionsToActionStateExecutionListAt(...)可复制既有状态或在执行列表中按位置插入动作。值得一提的是initialize()方法会先检查casProperties.getWebflow().getAutoConfiguration().isEnabled()只有自动配置开启时才会调用doInitialize()否则仅记录一条日志见 AbstractCasWebflowConfigurer.java#L128-L138。这与你稍后看到的cas.webflow.autoconfigure.enabled配置项直接对应。注册接入 CAS 应用运行时设计完成后需要把组件注册进 CAS 应用运行时package org.example; AutoConfiguration EnableConfigurationProperties(CasConfigurationProperties.class) public class MyAutoConfiguration { Bean public CasWebflowConfigurer myWebflowConfigurer( CasConfigurationProperties casProperties, Qualifier(CasWebflowConstants.BEAN_NAME_FLOW_DEFINITION_REGISTRY) FlowDefinitionRegistry flowDefinitionRegistry, ApplicationContext applicationContext, FlowBuilderServices flowBuilderServices) { return new MyWebflowConfigurer(flowBuilderServices, flowDefinitionRegistry, applicationContext, casProperties); } Bean public CasWebflowExecutionPlanConfigurer myWebflowPlanConfigurer( Qualifier(myWebflowConfigurer) CasWebflowConfigurer myWebflowConfigurer) { return plan - plan.registerWebflowConfigurer(myWebflowConfigurer); } }这里的几个关键点需要展开说明CasWebflowConstants.BEAN_NAME_FLOW_DEFINITION_REGISTRY的实际值是flowDefinitionRegistry对应的 Bean 名常量定义在 CasWebflowConstants同一份常量接口里还集中定义了数以百计的状态 ID 与动作 Bean 名例如STATE_ID_INIT_LOGIN_FORM initializeLoginForm、STATE_ID_VIEW_LOGIN_FORM viewLoginForm、STATE_ID_REAL_SUBMIT realSubmit、STATE_ID_SUCCESS success等编写配置器时建议直接引用这些常量而不是手写字符串。CasWebflowExecutionPlanConfigurer是一个函数式接口plan.registerWebflowConfigurer(...)会把你的配置器纳入 CasWebflowExecutionPlan 的统一执行计划。CAS 自身也正是这样做的在 CasWebflowContextConfiguration 中casDefaultWebflowExecutionPlanConfigurer依次注册了defaultWebflowConfigurer、defaultLogoutWebflowConfigurer与可选的groovyWebflowConfigurer并注册了 locale、resource、theme 等 Webflow 拦截器——你的自定义配置器会与这些内置配置器在同一计划中按Order顺序协同执行。配置类需要按照 配置管理扩展策略 注册到 CAS 中才能被自动装配机制发现。此外CAS 内置的groovyWebflowConfigurerBean 在 GraalVM 原生镜像Native Image下会被ConditionalOnMissingGraalVMNativeImage条件排除见 CasWebflowContextConfiguration.java#L299-L311因此在原生镜像环境中请优先考虑纯 Java 的扩展方式。关于编译的提示编译配置类以及放入 CAS Overlay 的任何其他 Java 代码可能需要额外的 CAS 模块与依赖位于 classpath 上。你需要研究 CAS 代码库找到包含所需组件例如CasWebflowConfigurer的正确模块。CasWebflowConfigurer及其配套接口定义在cas-server-core-api-webflow模块中而AbstractCasWebflowConfigurer的完整实现位于cas-server-core-webflow-api。方式二Groovy 脚本轻量但需谨慎如果你希望用更轻量的方式让 CAS 在运行时自动配置、改造 Webflow可以通过 Groovy 脚本实现。这种方式对 CAS API 的访问相对有限但 Overlay 的配置与依赖搭建更简单因为一切均由 CAS 在运行时提供。⚠️停止编码先想清楚这里提供的 API尤其作为 Groovy 脚本一部分执行的 API在很大程度上被视为 CAS 的内部实现。它们可能随时被添加或移除这意味着变更可能在运行时破坏你的部署与升级。与 Java 类不同脚本在构建 CAS 时不会被静态编译你可能只有在真正启动服务器部署时才会观察到失败。因此选择这个选项要有充分的理由并在编码前深思熟虑。配置启用 Groovy 支持要让 CAS 支持并集成 Apache Groovy请先阅读 Apache Groovy 脚本集成指南。之后通过以下配置属性启用 Webflow 自动配置配置项说明cas.webflow.autoconfigure.enabled是否启用 Webflow 自动配置默认true对应 WebflowAutoConfigurationProperties 中的enabled字段cas.webflow.groovy.locationGroovy 脚本的资源路径用于自动配置 Webflow 上下文动态创建/移除状态与动作对应 GroovyWebflowProperties 继承自SpringResourceProperties的location字段cas.webflow.groovy.actions.beanName以 Map 形式为指定 Webflow Action 的 Bean 名提供 Groovy 替代实现脚本路径这些属性的底层实现位于 WebflowProperties其中groovy嵌套属性明确注释为路径到可自动配置 Webflow 上下文的 Groovy 资源可动态创建/移除状态与动作。Webflow 自动配置脚本下面是一个示例 Groovy 脚本它定位 CAS 登录流程中预定义的一个状态如果找到就向该状态插入一个自定义动作使其在 CAS 进入该状态时立即执行。虽然这是一个相当朴素的例子但请注意该脚本有能力增删动作、状态、转移增删子流程等。import java.util.* import org.apereo.cas.* import org.apereo.cas.web.* import org.apereo.cas.web.support.* import org.apereo.cas.web.flow.* import org.springframework.webflow.* import org.springframework.webflow.engine.* import org.springframework.webflow.execution.* Object run(final Object... args) { def (webflow,springApplicationContext,logger) args logger.info(Configuring webflow context...) def loginFlow webflow.getLoginFlow() if (webflow.containsFlowState(loginFlow, CasWebflowConstants.STATE_ID_INIT_LOGIN_FORM)) { logger.info(Found state that initializes the login form) def state webflow.getState(loginFlow, CasWebflowConstants.STATE_ID_INIT_LOGIN_FORM, ActionState.class) logger.info(The state id is {}, state.id) state.getEntryActionList().add({ requestContext - def flowScope requestContext.flowScope def httpRequest WebUtils.getHttpServletRequestFromExternalWebflowContext(requestContext) logger.info(Action executing as part of ${state.id}. Stuff happens...) return new Event(this, success) }) logger.info(Added action to ${state.id}s entry action list) } return true }脚本接收的参数如下参数说明webflow一个门面对象封装了对 Spring Webflow API 的访问。它本身就是一个CasWebflowConfigurer在GroovyWebflowConfigurer.doInitialize()中CAS 把this作为第一个参数传入见 GroovyWebflowConfigurer.java#L28-L40因此getLoginFlow()、containsFlowState()、getState()等方法都可用springApplicationContextSpring 应用上下文logger日志对象用于输出如logger.info(...)之类的日志消息仓库中的测试用例 GroovyWebflowConfigurerTests 直接验证了这一机制它通过TestPropertySource(properties cas.webflow.groovy.locationclasspath:/GroovyWebflow.groovy)指向测试脚本并断言groovyWebflowConfigurer.initialize()不抛异常。Webflow Action 的 Groovy 替代实现Webflow 操作通常由实现了Action接口、并以Bean定义形式注册到 CAS 运行时的组件处理。虽然这些 Bean 定义可以被其他实现有条件地替换你也可以选择通过 Groovy 脚本接管动作实现本身——此时动作的实现责任完全转移到你手中CAS 不再为你提供实现。注意在提供 Groovy 替代实现之前你需要先仔细分析 CAS 代码库挖掘出原始动作Bean的名字。另外请注意并非所有 Spring Webflow 动作都能用 Groovy 等价替换。Groovy 在这一领域的支持是一个持续演进的过程会在各 CAS 版本中逐步完善请务必对照代码库确认。脚本的大致框架如下import org.apereo.cas.authentication.principal.* import org.apereo.cas.authentication.* import org.apereo.cas.util.* import org.springframework.webflow.* import org.springframework.webflow.action.* def run(Object[] args) { def (requestContext,applicationContext,properties,logger) args logger.info(Handling action...) return new EventFactorySupport().event(this, success) }脚本的返回值必须是 Spring Webflow 的Event对象。传入参数如下参数说明requestContext代表 Spring Webflow 执行上下文的对象携带 HTTP 请求与响应applicationContextSpring 应用上下文properties对 CAS 配置属性的引用即CasConfigurationPropertieslogger日志对象用于输出如logger.info(...)之类的日志消息从源码层面看这一机制由 GroovyScriptWebflowAction 实现它以{requestContext, applicationContext, casProperties, LOGGER}四个参数调用脚本并要求脚本返回Event类型。而 WebflowActionBeanSupplier 则负责条件装配——只有当cas.webflow.groovy.actions中存在对应 Bean 名的条目时才会用GroovyScriptWebflowAction替换原有的默认动作实现否则回落fallback到默认实现。这与 GroovyWebflowProperties 中关于key 为提供 Webflow 动作的 Bean 名/标识符、value 为 Groovy 脚本资源路径如file:/path/to/Script.groovy的注释完全吻合。仓库中同样带有可直接参考的测试资源 GroovyWebflowAction.groovy以及对应测试 GroovyScriptWebflowActionTests测试断言脚本执行后返回的EventID 与脚本内构造的result一致。从常量与源码看 CAS Webflow 的可扩展设计要写出健壮的扩展代码建议把 CasWebflowConstants 当作你的字典。这份接口文件长达数千行集中了Bean 名如BEAN_NAME_FLOW_DEFINITION_REGISTRY flowDefinitionRegistry、BEAN_NAME_FLOW_BUILDER_SERVICES flowBuilderServices状态 ID如STATE_ID_INIT_LOGIN_FORM、STATE_ID_VIEW_LOGIN_FORM、STATE_ID_REAL_SUBMIT、STATE_ID_SUCCESS、STATE_ID_LOGOUT_VIEW、STATE_ID_FINISH_LOGOUT等转移 ID 与动作 Bean 名如TRANSITION_ID_SUCCESS success、ACTION_ID_INIT_LOGIN_ACTION initializeLoginAction、ACTION_ID_AUTHENTICATION_VIA_FORM_ACTION authenticationViaFormAction、ACTION_ID_FETCH_TICKET_GRANTING_TICKET fetchTicketGrantingTicketAction等。在 Java 与 Groovy 两种方式中直接引用这些常量可以显著降低拼写错误与升级断链的风险。从整体设计来看CAS 的 Webflow 扩展遵循计划Plan 配置器Configurer的架构所有CasWebflowConfigurer通过CasWebflowExecutionPlanConfigurer注册进 CasWebflowExecutionPlan最终由execute()统一驱动初始化而AbstractCasWebflowConfigurer.initialize()中的cas.webflow.autoconfigure.enabled开关为整套机制提供了总闸。理解这条调用链后无论采用 Java 还是 Groovy你都能精确判断自己的扩展代码将在什么时机、以什么顺序生效。总结选型建议维度Java 自动配置组件Groovy 脚本能力上限完全访问 Spring Webflow API 与 CAS 辅助方法通过门面对象获得有限但够用的访问能力构建期安全编译期即可发现破坏性变更运行时才可能暴露问题配置成本需要额外依赖与模块研究Overlay 配置简单CAS 运行时提供一切升级风险较低随 CAS API 编译较高API 被视为内部实现可能随时变动适用场景复杂的、条件化的核心行为改造轻量的状态/动作插入与实验性改造对希望深度定制登录、登出等核心流程的团队Java 方案是最稳妥的长期选择对快速验证想法或做小范围调整的场景Groovy 脚本能显著降低门槛。无论选择哪种方式都请记住文档中的核心建议优先考虑把有价值的改动回馈给 CAS 项目本身避免在 Overlay 中维护一份永远要手动同步的私有补丁。如果发现 Webflow 自动配置策略未能按预期工作请在社区中提出讨论并提交修正缺陷或添加所需行为的补丁让改动落在它真正该在的地方。赞分享后端认证鉴权单点登录身份认证【免费下载链接】casApereo CAS - Identity Single Sign On for all earthlings and beyond.项目地址https://gitcode.com/gh_mirrors/ca/cas点击查看免费下载相关推荐Bootstrap Icons 中的 Diamond fill 图标SVG 源码、码点与实战用法详解Bootstrap Icons 中的 Diamond fill 图标SVG 源码、码点与实战用法详解 导读 本文以 Bootstrap Icons 开源图标库后端认证鉴权单点登录身份认证Apereo CAS Webflow 自定义装饰器用 Groovy 脚本为登录页注入动态数据Apereo CAS Webflow 自定义装饰器用 Groovy 脚本为登录页注入动态数据 本指南围绕 Apereo CAS 的 Groovy 登录装饰器后端认证鉴权单点登录身份认证Apereo CAS 自定义认证中断Custom Authentication Interrupt基于 InterruptInquirer 扩展登录流程Apereo CAS 自定义认证中断Custom Authentication Interrupt基于 InterruptInquirer 扩展登录流程后端认证鉴权单点登录身份认证上一篇使用 OHCI-1394 火线控制器物理 DMA 进行 Linux 内核调试从早期启动日志抓取到全内存转储下一篇dbt CoreRust 版贡献开发指南从环境搭建、代码质量门禁到 CHANGELOG 全流程解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考