ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

authentik Simplified Flow Executor(SFE):为老式浏览器引擎准备的 TypeScript 轻量 Flow 解释器

authentik Simplified Flow Executor(SFE):为老式浏览器引擎准备的 TypeScript 轻量 Flow 解释器 authentik Simplified Flow ExecutorSFE为老式浏览器引擎准备的 TypeScript 轻量 Flow 解释器【免费下载链接】authentikThe authentication glue you need.项目地址: https://gitcode.com/GitHub_Trending/au/authentik导读Simplified Flow Executor简称 SFE是 authentik 为兼容性问题准备的一个受限的浏览器端 Flow 语言解释器以 TypeScript 编写运行在浏览器中用于驱动 authentik 的 Flow 引擎与用户之间的交互。它的核心使命是让依赖MSEdge-18 与 IE-11 Trident 内核的老旧软件尤其是较新版本的 Microsoft Office365 与 Microsoft Teams依然能完成基于网页的登录流程。读完本文你将掌握 SFE 的定位、支持/不支持哪些 Flow Stage、服务器端如何判定并下发 SFE 页面、SFE 内部如何渲染并提交各 Stage 挑战以及它的构建与测试方式。SFE 是什么一个够用就好的浏览器端 Flow 解释器根据 web/packages/sfe/README.md 的定义Simplified Flow Executor 是 authentik 的 Flow 语言的一个有限的回退fallback浏览器端解释器。authentik 的 Flow 语言负责编排 authentik 服务器与用户之间、以及用户想要获得认证/授权的目标服务之间的整个事务流程——包括识别用户、校验密码、做 MFA 验证、重定向回应用等步骤。在默认情况下authentik 的前端是一个基于现代 Web 技术的复杂单页应用见 web/src它依赖 Web Components、现代 JavaScript 语法等能力。但部分存量软件内嵌的网页登录环境非常古老例如较新版本的 Microsoft Office365 与 Microsoft Teams 仍可能使用MSEdge-18与IE-11 的 Trident 渲染引擎这些引擎无法解析 authentik 默认 Flow 执行器的前端包。SFE 正是为这类场景诞生的降级方案它刻意保持功能受限只用极小的依赖jQuery lit-html 少量 polyfill实现一套能跑通登录闭环的最小解释器同时尽量兼容老式引擎。服务器端判定何时启用 SFESFE 并不是默认启用的而是由服务器根据请求的User-Agent动态决策。核心逻辑位于 authentik/flows/views/interface.py 的FlowInterfaceView.compat_needs_sfe()用户代理家族为IETrident 内核→ 启用 SFE用户代理家族为Edge且版本低于 19即 Legacy Edge 18 及更早MIN_EDGE_VERSION (19,)→ 启用 SFE。注释明确指出Edge 18 之后微软切换到 Chromium已能支持默认 Flow 执行器User-Agent 中包含PKeyAuth标记 → 启用 SFE。该标记来自 Microsoft 的microsoft-authentication-library-for-objcmacOS 上的 Microsoft Teams/Office 会携带它且同样使用非常陈旧的浏览器内核iOS 系统版本低于 16.4MIN_WEBKIT_VERSION (16, 4)→ 启用 SFE。因为 iOS 上所有浏览器都渲染在系统 WebKit 上iOS 版本决定了前端包能否被解析与用户打开的是哪个浏览器无关Safari / Mobile Safari 且 WebKit 版本低于 16.4→ 启用 SFE。这一条是为了覆盖 iPadOS 桌面模式——它会把自身报告为 macOS 上的 Safari上一条的 iOS 判断覆盖不到。模板选择逻辑在get_template_names()中当compat_needs_sfe()返回真或者请求 URL 中显式带?sfe参数时返回if/flow-sfe.html否则返回默认的if/flow.html。也就是说?sfe是一个强制进入 SFE 的调试/验证开关。这些判定规则在 authentik/flows/tests/test_interface_sfe.py 中有完整覆盖包括旧 WebKitiOS 15.x、旧 iOS 其他浏览器、旧 iPadOS 桌面模式、当前 WebKitiOS 16.4 走默认执行器、IE/Trident、Legacy Edge 18、当前 Chrome以及无法解析版本的未知 User-Agent回落到默认执行器等用例。SFE 页面骨架极简的服务器渲染模板当判定需要 SFE 时服务器渲染 authentik/flows/templates/if/flow-sfe.html。这个模板刻意保持最小化引入构建产物dist/sfe/bootstrap.min.css与dist/sfe/index.js前者由构建期拷贝的 vendored Bootstrap 提供见下文构建部分页面主体是一个 id 为flow-sfe-container的容器mainSFE 的所有挑战界面都由 JavaScript 渲染进这个容器背景使用 flow 配置的背景图flow_background_url并带Powered by authentik页脚通过base/header_js.html注入运行所需的数据。运行数据注入不依赖完整 API 客户端SFE 与主前端不同它刻意不拉取完整生成的 API 客户端主前端的等价实现位于 web/src/common/global.ts会引入庞大的生成代码。SFE 的上下文读取逻辑写在 web/packages/sfe/src/index.ts 中品牌信息从json_script块ak-brand读取API 基础地址从meta nameak-base-url读取。这两处数据由 authentik/core/templates/base/header_js.html 在服务端渲染{{ brand_json|json_script:ak-brand }} meta nameak-base-url content{{ base_url }}值得注意的是品牌块是序列化器的原始输出因此这里保留 snake_case 键名而不像主 bundle 那样做驼峰转换同时 SFE 页面不渲染暗色模式品牌 Logo 一律取branding_logo_themed_urls.light或回退到branding_logo。执行循环拉取挑战 → 渲染 → 提交 → 拉取下一个挑战SFE 的入口在 web/packages/sfe/src/index.ts 末尾new SimpleFlowExecutor($(#flow-sfe-container)[0]).start()。SimpleFlowExecutor的工作方式是一个典型的挑战-响应循环从window.location.pathname第 4 段解析出flowSlug即当前 flow 的标识start()先渲染加载动画然后向GET {base}/api/v3/flows/executor/{flowSlug}/?query...发起请求query参数透传当前页面的查询串拿到首个挑战challenge收到响应后用ChallengeTypesFromJSON解析为带component字段的挑战对象调用renderChallenge()用户在表单中提交数据后submit()将按钮置灰并显示 spinner把数据序列化为 JSON向同一 URL 发起POST并把响应的下一个挑战交给renderChallenge()。renderChallenge()根据挑战的component字段分发到对应的 Stage 渲染类component对应 Stage 类ak-stage-identificationIdentificationStageak-stage-passwordPasswordStagexak-flow-redirectRedirectStageak-stage-autosubmitAutosubmitStageak-stage-authenticator-validateAuthenticatorValidateStageak-stage-access-deniedAccessDeniedStage其他未知 component以 Unsupported stage: ... 错误渲染 AccessDeniedStage所有 Stage 继承自抽象基类StageT extends FlowInfoChallenge基类统一处理字段级错误responseErrors[fieldName]渲染为invalid-feedback与非字段错误渲染为alert-danger渲染均通过 lit-html 的render()写入容器。这也正是 README 所说只支持有限 Stage 集合的直接体现——遇到不支持的 Stage 时SFE 会明确给出 Access Denied 而不是静默失败。逐个 Stage 的实现细节Identification识别IdentificationStage渲染一个表单品牌 Logo、flow 标题、uid_field输入框若挑战带有passwordFields则额外渲染密码输入框认证流程可将识别与密码合并为一步。提交时用FormData收集数据并交给executor.submit()。渲染完成后自动聚焦uid_field。Password密码PasswordStage渲染Welcome, {pendingUser}.的只读欢迎行与密码输入框出错时密码框加is-invalid类并展示字段错误。提交后由服务器验证下一个挑战可能是重定向、MFA 或错误信息。Redirect重定向RedirectStage的实现最简单也最关键window.location.assign(challenge.to)直接让浏览器跳转到服务端指定的地址例如授权回调、SP 的登录地址。Autosubmit自动提交AutosubmitStage用于把数据以application/x-www-form-urlencoded的方式 POST 到第三方服务SAML/代理类流程的常见收尾。它渲染一个隐藏字段表单challenge.url作为 form 的actionchallenge.attrs中的每个键值对渲染为input typehidden并显示一个 spinner随后立即$(#autosubmit-form).submit()自动提交。Authenticator ValidationMFA 验证AuthenticatorValidateStage是 SFE 中逻辑最复杂的部分覆盖两类设备挑战静态恢复码 / TOTPdeviceClass为static或totp渲染一个code输入框带autocompleteone-time-code提交后交给服务器校验WebAuthn 安全密钥渲染 spinner 后调用navigator.credentials.get()。由于老式引擎无法直接消费服务器下发的二进制 challenge/credential IDSFE 先通过u8arr()将 Base64url 字符串还原为Uint8Array再传入PublicKeyCredentialRequestOptions拿到断言后transformAssertionForServer()把clientDataJSON、authenticatorData、signature、rawId等二进制数据重新编码为字符串含 URL-safe Base64 处理连同getClientExtensionResults()序列化结果一起以{ webauthn: assertion }形式提交给服务器验证。若deviceChallenges不止一个SFE 会先渲染一个选择认证方式的列表Recovery keys / Traditional authenticator / Security key点击后再进入对应的验证界面当存在 WebAuthn 但浏览器不支持时通过credentials in navigator与 HTTPS 检查该选项会被过滤掉。验证失败时回到选择界面重新尝试。构建与打包面向 IE 11 与 Edge 18 的降级产物SFE 包名为goauthentik/web-sfe见 web/packages/sfe/package.json其依赖刻意保持克制jquery、lit-html1.4.x 老版本、core-js、formdata-polyfill、weakmap-polyfill、webcomponents/template、base64-js以及链接自仓库的goauthentik/api。web/packages/sfe/rollup.config.mjs 展示了它的构建策略入口为src/index.ts输出到仓库级web/dist/sfe目录格式为 CJS、context: window用rollup/plugin-swc做转译env.targets明确指定edge: 17与ie: 11确保产物可被老式 Trident/旧 Edge 引擎解析rollup/plugin-node-resolve的extensions包含.ts/.tsx以解析链接进来的goauthentik/api源码一个自定义 copy 插件把vendored/bootstrap下的 CSS 拷贝到dist/sfe为老式引擎提供不依赖现代构建链的样式。这也解释了模板中dist/sfe/bootstrap.min.css与dist/sfe/index.js的来源。局限性与适用边界必须强调SFE 是受限实现README 明确列出其只支持identification、password、redirect、autosubmit、authenticator validationcode 与 WebAuthn。因此依赖 prompt、consent、captcha、email 等更多 Stage 的复杂 Flow在 SFE 下会落入Unsupported stage的 Access Denied 分支SFE 页面不渲染暗色模式视觉上固定使用浅色品牌 Logo它只服务认证闭环不承担管理界面等职责。从源码结构看SFE 的设计哲学是最小可行降级用服务器端 User-Agent 判定 一个极轻量的解释器换取 Office365/Teams 等旧登录环境下的可用性同时把功能面严格收敛到登录必需的 Stage 集合避免在兼容层上复制完整前端。如何验证与手动触发单元测试运行 authentik/flows/tests/test_interface_sfe.py 可验证compat_needs_sfe()对各类 User-Agent 的判定IE/Trident、Legacy Edge、旧 WebKit、iOS、iPadOS 桌面模式、现代浏览器、未知 UA 等。手动强制在任意 flow 的 URL 后追加?sfe查询参数即可绕过 User-Agent 判定强制加载 SFE 页面便于在现代化浏览器中调试 SFE 行为。许可证SFE 包的源码以 MIT License 发布许可证副本见 web/packages/sfe/LICENSE.txt包描述package.json中的license字段同样标注为 MIT。【免费下载链接】authentikThe authentication glue you need.项目地址: https://gitcode.com/GitHub_Trending/au/authentik创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表