* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* This (temporary) change is needed to prevent the unit tests from failing.
\# What
\# Why
\# How
\# Designs
\# Test Steps
\# Other Notes
* Revert "This (temporary) change is needed to prevent the unit tests from failing."
This reverts commit dddde09be5.
* website: fix bad escaping of URLs in release notes
## What
Fixes bad escaping of URLs in the release notes that resulted in mangled output.
v2024.6.4 had entries that looked like this:
```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```
v2025.4.md had entries that looked like this:
```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```
A couple of straightforward search-and-replaces has fixed the issue.
## Notes
Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.
@Beryju suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.
The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.
* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution
# What
Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.
# Why
1. Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2. Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.
* web/flow: clean up state representation in FlowExecutor
# What
Cleans up the state and lifecycle of FlowExecutor.
*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.
Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.
With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.
FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.
* web/flow: dedupe the set error flow state
# What
Extracts the logic for setting the flow state to FlowError.
# Why
It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.
* web/flow: dedupe the creation of fresh FlowApi instances
# What
Generates a single instance of FlowApi() that the FlowExecutor can use over the course of its lifetime.
# Why
Looking at the code generated by OpenApi, it’s clear that the parameters with which the API commits network transactions are immutable after construction; likewise, our particular invocation of `DEFAULT_GLOBALS` is also immutable with respect to a single instance of the FlowExecutor. With that in mind, there’s no reason to keep rebuilding the same network transaction object over and over; just instantiate it and live with it. In the conflict between rules-of-thumb “Never store what you can express” and “Extract repetitious expressions into instances,” the latter rule wins here.
* Intermediate. Gonna check against results.
* web/flow: extract inspector into standalone lifecycle
# What
Removes all of the code from `FlowExecutor` related to the inspector and isolates it into its own component. The lifecycle of FlowExecutor’s inspector handling has been adjusted to maintain the existing behavior.
# How
FlowExecutor is reduced to merely presenting the button:
- In `FlowExecutor`:
- Remove all the controls and references to FlowInspector
- Remove the capabilities check
- Remove the inspector listener
- Remove the render guards
- Remove the “inspect” PropVariant (and remove it from `FlowExecutorSelections`)
- Remove the inspector toggle
- Remove the inspector renderer
- Always dispatch FlowAdvance events (if the inspector is not present they will be ignored)
- Adjust `ak-stage-redirect` to not take “promptUser” as an attribute
- Replace the whole render-inspector-button clause with `ak-flow-inspector-button`
- Adjust CSS to use `ak-flow-inspector-button` instead of `.inspector-button`
RedirectStage now queries the context for inspector availability and state:
- In `stages/RedirectStage`:
- Change `promptUser` from a property accessor to a simple accessor that queries the parent context for the inspector state
- Remove the `@property` clause
FlowInspectorButton takes over these responsibilities, isolating this separate concern into a single file:
- Manages loaded, available, and open states
- Does the capabilities check
- Listens for FlowInspectorChangeEvents on the window object
- Renders nothing at all if the inspector is inaccessible or if the inspector is present and covering up the button
- On connectedCallback checks if the URL indicate the inspector should already be open
- Manages loading the FlowInspector on demand and toggles the drawer on state change
To my great surprise, `FlowInspector` itself required no changes.
* Initial experiment to move stages into the light.
* web/flow: clean up state representation in FlowExecutor (#20027)
* web/flow: clean up state representation in FlowExecutor
# What
Cleans up the state and lifecycle of FlowExecutor.
*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.
Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.
With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.
FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.
* web/flow: dedupe the set error flow state (#20029)
* web/flow: dedupe the set error flow state
# What
Extracts the logic for setting the flow state to FlowError.
# Why
It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.
* Protected.
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
* Fix types.
* web: Flesh out module driven tag names.
* Experiment continues: first-tier into the light.
* web/flow: optimize table for type safety
# What
Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)
* Prettier is still having opinions.
* web/flow: re-arrange IdentificationStage for maintainability
# What
Every conditional section of the IdentificationStage has been separated out into its own individual render function. Where possible, the information passed to the renderer has been reduced to a bare minimum (i.e if the function only needed the `passwordlessUrl`, that’s the only thing that’s passed to it), which helps highlight some inconsistencies in the API.
# No change
This is a purely maintenance-level change to the code, to make it obvious what needs to be plumbed/corrected in order to expose our dialogs to password managers. No functionality has been changed.
# Why
Figuring out how to turn our web components into proper elements, where what they contain is not isolated from the view of password managers, requires pulling out the functionality into small, readable components.
# Future work
Doing this has exposed several fundamental issues:
- auto-redirect is a state change from one LoginChallenge to another under a collection of conditions available on the challenge, triggered when FlowExecutor writes a new challenge. “Which challenge?” in FlowExecutor ought to be handling this, not handing it off to IdentificationStage.
- Everything about Captcha is about Captcha. It ought to be in its own little state managing class, perhaps as a lit controller.
- The same is true about WebAuthn.
- `host` is doing very little work; at best, it’s receiving a “change this” or “submit that” message, which is an Event. Look forward to that.
* Tidy.
* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit. The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed. The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.
* Removed comments about the cache. Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.
* Of COURSE prettier had opinions!
* Since the check for `this.can(CapabilitiesEnum.CanDebug))` has been moved into the FlowInspectorButton, FlowExecutor no longer needs the capabilities check at all.
* Move the inspector into its own folder.
* web: Flesh out stage mapping error handling. (#20292)
Co-authored-by: Ken Sternberg <ken@goauthentik.io>
* Weird merge bug: same function appeared twice.
* Added some visibility keys, as per @GirlBossRush
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
If you just follow orders exactly as said here it'll lead you to an error because of the strict policy having a slash at the end but in the seahub_settings.py in the docs tells you to put it without it. This minor change can help people to not encounter this minimal error sometimes difficult to see.
Signed-off-by: Diego Bravo <10383549+DystopianRescuer@users.noreply.github.com>
* autogenerate minor changes and API changes
* lint
* spellcheck
This is in a commit message, so technically it's not correct, but
at this point I don't care :))
* finalize release notes for `2026.2`
Update the GitHub social-login guide to consistently reference GitHub Developer Settings and correct provider wording.
Standardize GitHub capitalization across the page text and inline policy comments.
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* This (temporary) change is needed to prevent the unit tests from failing.
\# What
\# Why
\# How
\# Designs
\# Test Steps
\# Other Notes
* Revert "This (temporary) change is needed to prevent the unit tests from failing."
This reverts commit dddde09be5.
* website: fix bad escaping of URLs in release notes
## What
Fixes bad escaping of URLs in the release notes that resulted in mangled output.
v2024.6.4 had entries that looked like this:
```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```
v2025.4.md had entries that looked like this:
```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```
A couple of straightforward search-and-replaces has fixed the issue.
## Notes
Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.
@Beryju suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.
The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.
* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution
# What
Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.
# Why
1. Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2. Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.
* web/flow: clean up state representation in FlowExecutor
# What
Cleans up the state and lifecycle of FlowExecutor.
*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.
Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.
With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.
FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.
* web/flow: dedupe the set error flow state
# What
Extracts the logic for setting the flow state to FlowError.
# Why
It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.
* web/flow: dedupe the creation of fresh FlowApi instances
# What
Generates a single instance of FlowApi() that the FlowExecutor can use over the course of its lifetime.
# Why
Looking at the code generated by OpenApi, it’s clear that the parameters with which the API commits network transactions are immutable after construction; likewise, our particular invocation of `DEFAULT_GLOBALS` is also immutable with respect to a single instance of the FlowExecutor. With that in mind, there’s no reason to keep rebuilding the same network transaction object over and over; just instantiate it and live with it. In the conflict between rules-of-thumb “Never store what you can express” and “Extract repetitious expressions into instances,” the latter rule wins here.
* Intermediate. Gonna check against results.
* web/flow: extract inspector into standalone lifecycle
# What
Removes all of the code from `FlowExecutor` related to the inspector and isolates it into its own component. The lifecycle of FlowExecutor’s inspector handling has been adjusted to maintain the existing behavior.
# How
FlowExecutor is reduced to merely presenting the button:
- In `FlowExecutor`:
- Remove all the controls and references to FlowInspector
- Remove the capabilities check
- Remove the inspector listener
- Remove the render guards
- Remove the “inspect” PropVariant (and remove it from `FlowExecutorSelections`)
- Remove the inspector toggle
- Remove the inspector renderer
- Always dispatch FlowAdvance events (if the inspector is not present they will be ignored)
- Adjust `ak-stage-redirect` to not take “promptUser” as an attribute
- Replace the whole render-inspector-button clause with `ak-flow-inspector-button`
- Adjust CSS to use `ak-flow-inspector-button` instead of `.inspector-button`
RedirectStage now queries the context for inspector availability and state:
- In `stages/RedirectStage`:
- Change `promptUser` from a property accessor to a simple accessor that queries the parent context for the inspector state
- Remove the `@property` clause
FlowInspectorButton takes over these responsibilities, isolating this separate concern into a single file:
- Manages loaded, available, and open states
- Does the capabilities check
- Listens for FlowInspectorChangeEvents on the window object
- Renders nothing at all if the inspector is inaccessible or if the inspector is present and covering up the button
- On connectedCallback checks if the URL indicate the inspector should already be open
- Manages loading the FlowInspector on demand and toggles the drawer on state change
To my great surprise, `FlowInspector` itself required no changes.
* web/flow: clean up state representation in FlowExecutor (#20027)
* web/flow: clean up state representation in FlowExecutor
# What
Cleans up the state and lifecycle of FlowExecutor.
*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.
Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.
With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.
FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.
* web/flow: dedupe the set error flow state (#20029)
* web/flow: dedupe the set error flow state
# What
Extracts the logic for setting the flow state to FlowError.
# Why
It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.
* Protected.
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
* Fix types.
* web: Flesh out module driven tag names.
* web/flow: optimize table for type safety
# What
Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)
* Prettier is still having opinions.
* Tidy.
* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit. The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed. The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.
* Removed comments about the cache. Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.
* Of COURSE prettier had opinions!
* Since the check for `this.can(CapabilitiesEnum.CanDebug))` has been moved into the FlowInspectorButton, FlowExecutor no longer needs the capabilities check at all.
* Move the inspector into its own folder.
* web: Flesh out stage mapping error handling. (#20292)
Co-authored-by: Ken Sternberg <ken@goauthentik.io>
* Weird merge bug: same function appeared twice.
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* This (temporary) change is needed to prevent the unit tests from failing.
\# What
\# Why
\# How
\# Designs
\# Test Steps
\# Other Notes
* Revert "This (temporary) change is needed to prevent the unit tests from failing."
This reverts commit dddde09be5.
* website: fix bad escaping of URLs in release notes
## What
Fixes bad escaping of URLs in the release notes that resulted in mangled output.
v2024.6.4 had entries that looked like this:
```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```
v2025.4.md had entries that looked like this:
```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```
A couple of straightforward search-and-replaces has fixed the issue.
## Notes
Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.
@Beryju suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.
The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.
* web/maintenance/no-unknown-attributes-1
# What
This commit is a collection of fixes and adaptations discovered while running lit-analyzer in a stricter role than usual. These fixes are to 9 of the existing issues; there are 16 more that will be addressed in the next two pull requests.
The following issues were uncovered.
- `ak-slug-input` does not take `autocomplete`.
- `ak-wizard-page-type-create` does not take, or use, the `name` attribute. It also has no `value` of its own, so it is not processed as a form object.
- `ak-endpoints-device-access-groups-form` does not take a `pk` attribute. It takes an `.instancePk` property.
- `ak-provider-oauth2-redirect-uri` is only used in one place, and that place uses the term `input-id` for the key. The component was expected `inputId`. Since it is a string and therefore an attribute, kebab-case is the appropriate fix here.
- `input-mode` is not a valid attribute. The attribute is `inputmode`, and the property is `inputMode`. It may not be undefined. If it is defined, the default is `text`. I have fixed this in the attribute and in the two Forms that used it.
- `form-associated-element` had both `name` and `type` as readonly. Since they are native attributes, they can be attributes or they can be readonly. They can’t be both. I have made them read-write.
- `user-source-settings-page` is only used in one place, and that place uses the term `input-id` for the key. The component was expected `inputId`. Since it is a string and therefore an attribute, kebab-case is the appropriate fix here.
These guideposts will be placed on the PR.
* Update web/src/admin/providers/oauth2/OAuth2ProviderRedirectURI.ts
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
* Update web/src/components/ak-text-input.ts
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
* web/maintenance/no-unknown-attributes-2
# What
This commit is a collection of fixes and adaptations discovered while running lit-analyzer in a stricter role than usual.
- `src/admin/endpoints/connectors/agent/AgentConnectorSetup.ts`
After talking to @beryju, we determined that these labels aren’t shown and aren’t used.
- `src/admin/admin-overview/AdminOverviewPage.ts`
- `src/admin/admin-overview/DashboardUserPage.ts`
- `src/elements/cards/AggregatePromiseCard.ts`
- `src/elements/cards/stories/AggregatePromiseCard.stories.ts`
The `Promise` version of our card is not used by any client code. The Dashboard pages that were importing it want the vanilla `AggregateCard` instead.
- `./src/flow/stages/identification/IdentificationStage.ts`
Anchors do not have a `name` attribute, I cannot find any code using the name attributes as lookups, nor any CSS that might use the name attributes as guides. `ak-flow-password-input` is always required; the flag is unsupported and unnecessary.
- `./src/flow/stages/password/PasswordStage.ts`
Anchors do not have a `name` attribute, I cannot find any code using the name attributes as lookups, nor any CSS that might use the name attributes as guides. `ak-flow-password-input` is always required; the flag is unsupported and unnecessary.
- `src/user/user-settings/UserSettingsPage.ts`
This change to the `UserSettingsPage`:
``` diff
- userId=${ifPresent(currentUser?.pk)}
+ user-id=${ifPresent(currentUser?.pk)}
```
… corresponds correctly with:
``` typescript
@property({ type: Number, attribute: "user-id" })
public userId?: number;
```
I find it odd (and remarkable) that nobody has complained about this yet. I even went so far as to [confirm my understanding](https://codepen.io/kensternberg-authentik/pen/raLNBwO) and, yes:
- when an attribute is truthy, property syntax does not set the field
- when an attribute is deliberately given a kebab-case name, using the camelCase variant does not set the field
However, when the attribute is truthy, attribute names are case-insensitive: ‘user-id’ and ‘User-Id’ in client code would work just fine.
## Note
A large enough number of warnings remain. Some of those are due to `lit-analyzer` not being updated to recognize newly Baseline global DOM properties like `inert` or `popover`. The rest are from RapiDoc and QrCode, which do not supply sufficient documentation or metadata for Lit-anaylzer to read correctly.
* web/bug/hidden-secrets-not-propagating
# What
This commit updates ak-secret-text-input, adding the `name` attribute to all valid input fields and updating the value writer to match those of known-working components, to ensure that either variety of the display is fully and correctly updated with the content of the hidden secret.
# Why
The hidden input field is the one that HorizontalFormElement was expecting to read its value from, but that field never received a `name` because it wasn’t present when the field was first updated.
HorizontalFormElement writes the `name` field to the first `<input>` it finds. That was the “dummy” input field, which has no working value.
Form ignored the input element because the value it read came with an undefined name.
Object-oriented state management sometimes bites.
* Turns out, I was wrong. Someone *does* use the `name` attribute: the tests. MDN says that `name`
is incorrect, and we should use `id` instead. I have compromised; I have switched to using the
Open UI Automation ID instead, since that's what we're doing: automated tests.
\# What
\# Why
\# How
\# Designs
\# Test Steps
\# Other Notes
---------
Signed-off-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Co-authored-by: Jens L. <jens@goauthentik.io>
* add info about make install and recovery key
* fix formatting on troubleshooting tip
* Apply suggestion from @dominic-r
Signed-off-by: Dominic R <dominic@sdko.org>
* tweak to bump
* tweak
* tweaked words abouot make install per jens
* build
---------
Signed-off-by: Dominic R <dominic@sdko.org>
Co-authored-by: Dominic R <dominic@sdko.org>
Co-authored-by: Marcelo Elizeche Landó <marcelo@goauthentik.io>
Use r.URL.EscapedPath() instead of r.URL.Path when building the
redirect URL in redirectToStart(). The decoded Path field converts
%2F to /, which url.JoinPath then collapses via path.Clean, stripping
encoded slashes from the URL. EscapedPath() preserves the original
encoding, fixing 301 redirects that break apps like RabbitMQ which
use %2F in their API paths.
* Use `extract_client_auth` which can get client id from either HTTP
Authorization header or POST body
* Update documentation to reflect allow sending client id via header
* Add tests for using HTTP Basic Auth to pass in client id
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* This (temporary) change is needed to prevent the unit tests from failing.
\# What
\# Why
\# How
\# Designs
\# Test Steps
\# Other Notes
* Revert "This (temporary) change is needed to prevent the unit tests from failing."
This reverts commit dddde09be5.
* website: fix bad escaping of URLs in release notes
## What
Fixes bad escaping of URLs in the release notes that resulted in mangled output.
v2024.6.4 had entries that looked like this:
```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```
v2025.4.md had entries that looked like this:
```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```
A couple of straightforward search-and-replaces has fixed the issue.
## Notes
Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.
@Beryju suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.
The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.
* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution
# What
Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.
# Why
1. Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2. Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.
* web/flow: clean up state representation in FlowExecutor
# What
Cleans up the state and lifecycle of FlowExecutor.
*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.
Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.
With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.
FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.
* web/flow: dedupe the set error flow state
# What
Extracts the logic for setting the flow state to FlowError.
# Why
It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.
* web/flow: dedupe the creation of fresh FlowApi instances
# What
Generates a single instance of FlowApi() that the FlowExecutor can use over the course of its lifetime.
# Why
Looking at the code generated by OpenApi, it’s clear that the parameters with which the API commits network transactions are immutable after construction; likewise, our particular invocation of `DEFAULT_GLOBALS` is also immutable with respect to a single instance of the FlowExecutor. With that in mind, there’s no reason to keep rebuilding the same network transaction object over and over; just instantiate it and live with it. In the conflict between rules-of-thumb “Never store what you can express” and “Extract repetitious expressions into instances,” the latter rule wins here.
* web/flow: clean up state representation in FlowExecutor (#20027)
* web/flow: clean up state representation in FlowExecutor
# What
Cleans up the state and lifecycle of FlowExecutor.
*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.
Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.
With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.
FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.
* web/flow: dedupe the set error flow state (#20029)
* web/flow: dedupe the set error flow state
# What
Extracts the logic for setting the flow state to FlowError.
# Why
It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.
* Protected.
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
* Fix types.
* web: Flesh out module driven tag names.
* web/flow: optimize table for type safety
# What
Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)
* Tidy.
* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit. The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed. The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.
* Removed comments about the cache. Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.
* web: Flesh out stage mapping error handling. (#20292)
Co-authored-by: Ken Sternberg <ken@goauthentik.io>
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* This (temporary) change is needed to prevent the unit tests from failing.
\# What
\# Why
\# How
\# Designs
\# Test Steps
\# Other Notes
* Revert "This (temporary) change is needed to prevent the unit tests from failing."
This reverts commit dddde09be5.
* website: fix bad escaping of URLs in release notes
## What
Fixes bad escaping of URLs in the release notes that resulted in mangled output.
v2024.6.4 had entries that looked like this:
```
##### `GET` /providers/google_workspace/{#123;id}#125;/
```
v2025.4.md had entries that looked like this:
```
##### `GET` /policies/unique_password/{#125;#123;policy_uuid}/
```
A couple of straightforward search-and-replaces has fixed the issue.
## Notes
Two of the release notes had bad escaping of URLs. I'm not sure how the error was made or got past,
but it was obvious when visiting the page.
@Beryju suggested that the bug is due to our using `{...}` to symbolize parameters in a URL while
Docusaurus wants to interpret `{...}` as an internal template instruction, resulting in odd
behavior. In either case, docusarus interpreted the hashtagged entries as links to unrelated issues
in Github (the same two issues, which were "bump version of pylint" and "bump version of sentry"),
which could be very confusing.
The inconsistencies between the two releases, and the working releases, suggests that the error was
introduced manually.
* web/flow: refactor FlowExecutor so that client-side stage selection is separate from stage execution
# What
Extracts and normalizes the *massive* switch/case statement into a table, eliminating as much repetition as possible. Where the server-side stage token and the client-side component have the same tag, only one is required. There were three different patterns for prop definitions, and those have been regularized into an expression with a compile-time type check, and the most common one can be omitted from the stage definition table.
# Why
1. Because it’s hella cleaner. Stages are clear and easy to spot in the table (especially when it’s alphabetically ordered, OMG). Stages that disagree in name with their components, stages that take props different from the “standard” set, and stages that need `import` statements, are all easy to identify.
2. Because identifying what we *do* with our web components is critical to their success, and to the success of the styling system the authentik web team envisions. FlowExecutor provides selection and execution of stages, but it also provides the inspector, the locale selector, headers, footers, customizations, and branding. Clearing away clutter to make that easier to see makes future refactoring for compatibility mode and dark theme handling much easier.
* web/flow: clean up state representation in FlowExecutor (#20027)
* web/flow: clean up state representation in FlowExecutor
# What
Cleans up the state and lifecycle of FlowExecutor.
*As state lifecycle*, the two fields `challenge` and `flowInfo` are synonymous: they are modified at the same time, once in the setter, and once in `updated()`; flowInfo is always a derived consequence of that current challenge. Making `challenge` the property that we are monitoring and `flowInfo` a simple accessor on `challenge` eliminates duplication of state management.
Lit automatically schedules a re-render whenever `challenge` is changed; the `requestUpdate()` is therefore not needed.
With that, the only thing left is where or when to change the document title. That too is moved to `updated()` and happens without checking for need; it does no harm to replace a string with its own value, the performance loss is so small as to be non-existent, it will not confuse the browser or the environment. Eliminating an `if` and reducing the code surface to a pattern check is a win.
FlowExecutor now has only three states: Loading, Challenge Available, and… Inspector? Let’s see what we can do about cleaning these up as well. Loading and Challenge do not seem synonymous: the challenge should not be altered until the fetch is complete, to prevent blank displays.
* web/flow: dedupe the set error flow state (#20029)
* web/flow: dedupe the set error flow state
# What
Extracts the logic for setting the flow state to FlowError.
# Why
It was just duplication. Trying to clean up state management is easier when special state handling is isolated into a single method.
* Protected.
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
* Fix types.
* web: Flesh out module driven tag names.
* web/flow: optimize table for type safety
# What
Separate out the “here’s how a stage is defined” from “Here’s how a stage is represented internally.” This gives us a nice central store of where to define how the server-side componentName relates to a client-side customElementName while also guaranteeing that the componenName or supplied customElementName exists and corresponds. Type safety has been preserved system-wide (thanks, @GirlBossRush!)
* Tidy.
* Removed the cache; it's extra code for no benefit whatsoever; the table is constructed ONCE at start-up, there's never going to be a cache hit. The FlowExecutorStageFactory produces StageMappings (StageMapping[]), which is itself a warehouse of singular server-component -> client-component relationships, fetching the client from the bundle as needed. The StageMapping only does the fetch once per instance, so (for example) a password failure will reinstantiate a PasswordStage, but it will not fetch it a second time.
* Removed comments about the cache. Added comments about where to find the FlowExecutor stage table. Moved the import of WebAuthnAuthenticticatorRegisterState from FlowExecutor.ts to FlowExecutorStages.ts; both files are bundled together, so this is a no-op functionally, but it's easier to confirm that StageEntries without import expressions (STageModuleCallbacks) have their stages bundled (pre-imported) if the import statement is in the same file.
* web: Flesh out stage mapping error handling. (#20292)
Co-authored-by: Ken Sternberg <ken@goauthentik.io>
* Restore fallback to use token if neither tag nor import are present.
* Bad check.
---------
Co-authored-by: Teffen Ellis <592134+GirlBossRush@users.noreply.github.com>
Update OIDC configuration formatting
The original documentation caused an error with the current gatus version. It has been fixed with the correct formatting.
Signed-off-by: Kofl <thomas@kofler.tk>
* web/admin/bugfix: Edit Stage not working. Invoking IdentificationStageForm not working.
## What
1. Fix the field being referenced by Flows -\> \[One Flow\] -\> StageBindings -\> \[Edit Stage\] to use the PK for the *stage*, rather than the *binding*.
2. Added a check in `StrictUnsafe`: if the property is “wrapped” and untyped, treat it as an attribute, not a property.
3. Edit the `ak-bound-stages-list` target attribute to be an attribute, not a property.
## Why
1. This looks like a simple typo. To avoid this in the future, *we need tests*.
2. `ModelForm` uses both a converter and get/set accessors to manage the pk (primary key) of the object it is being invoked to edit: the first because Django primary keys can be either strings or numbers, and the latter because we have special transactional requirements when a primary key changes. Lit’s magic for handling this creates some weirdness around JavaScript prototyping (`wrapped` becomes the only key on the object; all the other keys become delegated to a prototype object), so `hasOwn()` can’t be used; we just have to check for `wrapped` and `!type`.
3. PKs are either strings or numbers, and ModelForm has a smart converter. There’s no need to shove the values around as properties and, in fact, that’ll break some things because there’s a working `attribute` field on ModelForm! Removing the `.` property marker both avoids this issue and makes visible exactly what item-id is being referenced.
* Forced update of package lock. AGAIN.
* Sigh
* Sigh. Again.
* Sigh. But this time, with an empty cache.
* Prettier and its opinions.
* Clearing the cache broke relationships inside SFE. That has been updated.
* WTF, over?
* Update permission name from 'Can view Admin interface' to 'Can access admin interface'
based on the current 2025.12 release
Signed-off-by: Kofl <thomas@kofler.tk>
* Fix other references to old permission name
---------
Signed-off-by: Kofl <thomas@kofler.tk>
Co-authored-by: Dewi Roberts <dewi@goauthentik.io>
* website/integrations: add OIDC method for Zammad
* Minor changes
* Add configuration verification
* Update index.md
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Update SAML instructions for Zammad
* wip
---------
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
Co-authored-by: Dewi Roberts <dewi@goauthentik.io>
Co-authored-by: Dominic R <dominic@sdko.org>
