* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* web/update: update `secret text` to enable password-like inputs
# What
Adds a flag to ak-secret-text-input so that most secret texts are more password-like than plain-text-with-hidden. plain-text-with-hidden can still be enabled.
# Why
Some customers were uncomfortable with fields named “password” showing input as plain text during object creation.
* web/update: update `secret text` to enable password-like inputs
# What
Adds a flag to ak-secret-text-input so that most secret texts are more password-like than plain-text-with-hidden. plain-text-with-hidden can still be enabled.
# Why
Some customers were uncomfortable with fields named “password” showing input as plain text during object creation.
* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* web/bugfix: Device user/group/policy bindings not being recorded correctly
## [Issue 22387](https://github.com/goauthentik/authentik/issues/22387)
> When manually binding a user to a device via Admin → Endpoints → Devices → \[Device\] → Users/Groups tab → Create or bind, the binding is incorrectly created as a PolicyBinding (authentik_policies) instead of a DeviceUserBinding (authentik_endpoints).
>
> As a result, the Users/Groups tabs on the Device detail page remain empty even after the binding is created.
## What has been changed:
A new flag, `no-wizard`, has been added to the attributes taken by `ak-bound-policies-list`; when set, this flag overrides the default behavior of offering `ak-policy-wizard`, and instead falls back to `ak-policy-binding-form`, which has the correct behavior. This limits the capability to create new policies for devices, but most of the time admins want to bind an existing User or Group, so this is probably not a large takeaway at the moment.
## Why
This is an annoying bug. As I understand the problem, `DeviceUserBindingForm` is the *only* feature that inherits from `PolicyBindingForm`. It is the `DeviceUserBindingForm`, not the wizard, that supports calling the `endpointsDeviceBindings(Update/Create)` method correctly. In the long term, we could do some sort of inheritance / endpoint override thing with the wizard, but for the moment that’s a bigger lift.
The simplest fix was to add a flag to *force* `BoundPoliciesList` to pick the (overridable) `*BindingForm` over the (not so overridable) wizard; this passes through the inheritance chain from `BoundDeviceUsersList` to trigger the correct behavior.
## Other fixes
We duplicate both the “validate policy type” and “clean binding to be sent” code in multiple places; I have de-duplicated them.
* stages/captcha: add Cap and JSON verification support
Add a configurable verification request content type so CAPTCHA providers can use either form-encoded or JSON token verification.
Add Cap as a preset and flow controller, including module-script loading, interactive widget handling, generated API/client types, tests, and docs.
* web/admin: clarify Cap captcha configuration
Treat the Cap endpoint as a form-only alias for the existing public key field and document Cap alongside the other CAPTCHA providers.
Agent-thread: https://sdko.org/internal/threads/019e737a-314e-72d0-98ae-201cb855df3a
A7k-product: product
A7k-product-repo: 2
Co-authored-by: Agent <agent@svc.sdko.net>
* stages/captcha: prefer self-hosted Cap widget URL
Default the Cap provider guidance to the self-hosted widget asset and keep CDN usage pinned to reviewed releases.
Agent-thread: https://sdko.org/internal/thr/ak/019ead31-2435-7e12-b933-e873155d6894
A7k-product: product
A7k-product-repo: 2
Co-authored-by: Agent <agent@svc.sdko.net>
* floating
---------
Co-authored-by: Agent <agent@svc.sdko.net>
Co-authored-by: Simonyi Gergő <28359278+gergosimonyi@users.noreply.github.com>
* web/polyfill: polyfill customElements.getName for Safari < 17.4
The flow renderer started calling window.customElements.getName in 2026.5,
which crashes on iOS 16 Safari and any WebKit WebView before 17.4. Reporters
saw "getName is not a function" at the first stage render and the page never
recovered.
The polyfill wraps define() to record each tag and constructor pair, then
resolves getName(ctor) from that map. It only installs when the registry is
missing the method, so modern browsers keep their native implementation. The
polyfill bundle is loaded from base/skeleton.html ahead of every interface
entry point, so the wrap is in place before any customElements.define call
runs.
Fixes#22611
Co-Authored-By: Agent (authentik-i22611-committed-cooperative-orchid) <279763771+playpen-agent@users.noreply.github.com>
* Refine.
---------
Co-authored-by: Agent (authentik-i22611-committed-cooperative-orchid) <279763771+playpen-agent@users.noreply.github.com>
Co-authored-by: Connor Peshek <connor@connorpeshek.me>
* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* web/maintenance: eliminate the need for DEFAULT_CONFIG boilerplate everywhere
# Promise:
There is only one file change in the entire PR. I promise. It is `./web/src/common/api/client.ts`.
Every other change is mechanical.
# What
Replace the repetitive boilerplate of importing DEFAULT_CONFIG everywhere by replacing it with an enclosing function that does both instantiation and configuration for you.
# How !?!?!?! (I hear you cry)
Read the `client.ts` file. It shows you the new mechanism.
# Mechanical update:
Every other change to the source code was performed with the following seven-line script: use `prettier --print-width 400` to ensure all the construction expressions would be single-line (they weren’t necessarily always so); identify the files that used `DEFAULT_CONFIG`, replace their `import` statements, replace their instantiation expressions, then clean up the debris.
$ ./node_modules/.bin/prettier --cache --write -u . --print-width 400
$ rg -l 'import.*\{ DEFAULT_CONFIG \}' ./src > client-only.txt
$ perl -pi.bak -e 's{import \{ DEFAULT_CONFIG \} from "\#common/api/config"}{import \{ aki \} from "#common/api/client"}' $(cat client-only.txt )
$ perl -pi.bak -e 's{new ([A-Z][A-Za-z]+Api)\(DEFAULT_CONFIG\)}{aki(\1)}g' $(cat client-only.txt )
$ rm client-only.txt
$ find . -name '*.bak' -exec rm {} \;
$ npm run prettier
The dark theme overrides in ak-pagination assigned the disabled color
variable to the active button and the active color variable to the
overridden disabled-color custom property. As a result, the active arrow
appeared muted and the disabled arrow appeared highlighted on the first
and last pages of paginated lists.
Swap the two values so the active arrow uses the m-plain color and the
disabled custom property keeps the m-plain disabled color.
Closes#22607
Co-authored-by: nicedevil007 <nicedevil007@users.noreply.github.com>
Rename the PFColor.Grey enum member to Gray and the FONT_COLOUR_*/fontColour chart identifiers to FONT_COLOR_*/fontColor (PatternFly's pf-m-grey CSS class is left as-is), plus American spellings in comments and a UI string. Part of enabling cspell's British-spelling rule; the rule itself lands in a separate PR once all areas are clean.
Co-authored-by: Playpen Agent <279763771+playpen-agent@users.noreply.github.com>
* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* web/maint: Move sync into the components folder; adjust imports accordingly
# What
1. Moves the sync folder from elements to components: sync is very API-aware.
2. Adjusts all the imports correctly.
* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* web/maint: move special-purpose support elements closer to what they support
Moves the `./element/oauth` components to `./admin/users`. They're API-aware (so they're components, not elements) and they're not general-purpose (used only by Admin, so they should be closer to where they're used).
Not sure why `uv.lock` changed.
\# What
\# Why
\# How
\# Designs
\# Test Steps
\# Other Notes
* This should not be different.
* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* web/maint: Move notifications into the components folder; adjust imports accordingly
# What
1. Moves the notifications folder from elements to components: the API and Notifications drawers are API-aware. If we want to separate that out and do something unique, we can, but for now, let’s just get things where they should be.
2. Adjusts all the imports correctly.
3. (Minor): Mutating the array and then calling `requestUpdate()`, especially when the array is then sorted-and-reversed, doesn’t save anything over creating a new array with the new item shifted onto the head, sorted once, and then saved to the property, which triggers an update automatically.
* web/table: fetch on first render when already visible
Tables inside `<ak-modal>` rendered empty until the user clicked the
refresh button. The 2026.5 RC native-`<dialog>` migration taught
`AKModal.updated()` to force `visible = true` on its slotted child, but
`Table.firstUpdated()` was delegating to `#synchronizeRefreshSchedule()`,
which only flushes a *previously deferred* refresh. With visibility
forced on before the first update cycle, no deferred refresh was ever
queued, so the synchronizer no-op'd and nothing fetched.
Switch the first-update hook to call `fetch()` directly. `fetch()`
already handles both states correctly: if the table is visible it
issues the request immediately, and if it isn't it queues the deferred
refresh that the synchronizer flushes when visibility flips on. Beyond
the modal case this also covers any future caller that mounts a Table
already-visible.
Reproduced and verified against the user-library RAC endpoint launcher
(the surface from the beta report). Added a Playwright e2e
(`rac-launch-modal.test.ts`) that seeds a RAC provider + two endpoints
via the API, opens the launcher, and asserts the endpoint rows appear
without a manual refresh — fails on `main`, passes with this change.
A 2026.5 backport will follow as a separate PR.
Co-Authored-By: Agent (authentik-m-triage-rac-proper-shared-lilac) <279763771+playpen-agent@users.noreply.github.com>
* web/test: silence cspell on AK_TEST_BOOTSTRAP_TOKEN fallback
`changeme` in the playpen-specific default for `AK_TEST_BOOTSTRAP_TOKEN`
trips the spellcheck lint job. Add an inline `cspell:ignore` directive
so the fallback can stay (CI sets the env var so the default is only
used locally inside playpen sandboxes).
* Flesh out RAC test coverage.
* Use simple search for applications list.
* Add order.
* Ignore playwright result.
* Remove unused.
* Tidy for test.
* Fix test selectors.
* Fix overlap.
* Defer to connected callback.
* Use consistent Patternfly input outline.
* Clean up labels.
* Only trigger navigation on non-current entries.
* Ensure that selected type is retained.
---------
Co-authored-by: Agent (authentik-m-triage-rac-proper-shared-lilac) <279763771+playpen-agent@users.noreply.github.com>
Ken Sternberg
Marcelo Elizeche Landó
dependabot[bot]
Teffen Ellis
authentik-automation[bot]
Dominic R
NiceDevil
Jens L.
Connor Peshek
transifex-integration[bot]