* internal: make http timeouts configurable
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* Changed formatting to match the rest of the doc
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Dewi Roberts <dewi@goauthentik.io>
* Begin
* WIP
* WIP
* WIP
* Fix link
* Fix spellig and links
* Enterprise vs enterprise plus
* Changes based on Tana's comment
* Update website/docs/enterprise/enterprise-features.md
Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Update website/docs/enterprise/enterprise-features.md
Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Update website/docs/enterprise/enterprise-features.md
Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Update website/docs/enterprise/enterprise-features.md
Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Apply suggestions
* Apply suggestion from Eric
* Update doc title after discussion with Tana
* Fix links
* Update website/docs/enterprise/manage-enterprise.mdx
Co-authored-by: Dominic R <dominic@sdko.org>
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Update website/docs/enterprise/manage-enterprise.mdx
Co-authored-by: Dominic R <dominic@sdko.org>
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Apply suggestions
* US dollars
* Apply Fletcher's suggestions
---------
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
Co-authored-by: Dominic R <dominic@sdko.org>
* 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>
## What
Re-arranges where types are declared and how they’re accessed. In some cases, refine the types to provide stronger build-time guarantees.
## Why
A lot of our stages use bits and pieces of types from a base state, from the executor, and in some cases from redundant sources.
Union types are great for some things, but Typescript can get really hung up on passing a union type as a function parameter when there’s some low-level non-conformance across all the types in the union. Because OpenAPI doesn’t do abstractions, this commit introduces a `StageChallengeLike`, which abstracts all of the Challenge types, asserting that there is a unifying parent class that contains the minimum collection fields found across all challenges, and this lets us address the different challenge types and their corresponding components before worrying about refining the type for construction and deployment.
On the other hand, sometimes you want to be able to assert that *all* of the member of a union correspond to some shape of data, and you can always use `Pick<>` on the FormChallenge type to assert that at build time.
Other than that, this centralizes the types into locations in the codebase with well-known names.
Update authentik configuration steps
Removed the noting of 'slug' from the authentik configuration steps, as its not required on the Beszel site
Signed-off-by: Kofl <thomas@kofler.tk>
## What
Provide dynamically imported dialogs and forms a default export.
Some minor cleanup of types: `PropertyValues` -\> `PropertyValues<this>` provides stronger type guarantees.
## Why
We define stages and other dynamic processes on the server side using a token, the server-side component name. Client-side elements are instantiated with a constructor and identified with an element tag name.
Dynamically importing components automatically registered the element tag name with the constructor, enabling custom elements to work. Without the default export, the registration goes to the browser but the identity of the component’s underlying constructor is lost. Browsers provide a reverse lookup: given a component’s constructor it can provide the registration tag. By having default exports, we allow dynamic imports to record the constructor, retrieve the tag, and dynamically construct the templates without having to manually maintain the tag/constructor relationship (which is already complicated enough by that server-side component/client-side element relationship).
## Testing
This is purely internal maintenance; it’s about hardening the build, not changing behavior. If it lints and builds cleanly, the only real test is that nothing is borken afterwards.
## What
Names being passed to the browser were being incorrectly rendered. This commit updates the code in `StrictUnsafe` so that after the correct-use assertion is passed, the elementProperties are checked to see if the attribute has been named differently from the typed attribute field, and if so, retrieves the attribute name and passes it, rather than the field name, to the browser.
## Why
Since we have a lot of components with similar interfaces, it makes sense to try and check that they’re being used correctly and that the types associated with them are correct. Plus Lit, unlike React, doesn’t have a self-erasing syntax: every Lit element *is* an element, whereas JSX is an esoteric function call syntax that happens to look like XML. JavaScript templates aren’t as pretty as JSX, but they get the job done just as readily.
But in this case, cleverness bit us: we want to use the component’s JavaScript field names and types to validate that we’re using it correctly and passing the right types, but in the end we’re constructing a tag that will trigger the browser to construct the component and use it– and the field names don’t always correspond to the attribute name. Lit has a syntax for mapping the one to the other and stores it in the `elementProperties` field.
This code checks that, after we’ve determined the correct prefix for an property field that has been passed into the component, that we’ve also checked and extracted the correct *attribute name* for that property field. Most of the time it will be the same as the property field, but it muts always be checked.
* Begin
* Add steps
* Apply suggestions
* Update website/docs/users-sources/sources/social-logins/okta/index.md
Co-authored-by: Dominic R <dominic@sdko.org>
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
* Apply suggestion from @dominic-r
Signed-off-by: Dominic R <dominic@sdko.org>
---------
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
Signed-off-by: Dominic R <dominic@sdko.org>
Co-authored-by: Dominic R <dominic@sdko.org>
* Addresses issues in doc
* Apply suggestion from @dominic-r
Signed-off-by: Dominic R <dominic@sdko.org>
---------
Signed-off-by: Dominic R <dominic@sdko.org>
Co-authored-by: Dominic R <dominic@sdko.org>
* Update index.mdx
This change is response to a know issue with the sso needing to map to the users username not email which is default. This clarification should be provided to prevent errors see the following. https://github.com/fosrl/pangolin/issues/639
Signed-off-by: kgoode517 <Kgoode517@yahoo.com>
* Apply suggestion from @dominic-r
Signed-off-by: Dominic R <dominic@sdko.org>
---------
Signed-off-by: kgoode517 <Kgoode517@yahoo.com>
Signed-off-by: Dominic R <dominic@sdko.org>
Co-authored-by: Dominic R <dominic@sdko.org>
* website/docs: Custom CSS
* Revise.
* Fix paths.
* Update links.
* Update header capitalization
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
---------
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
Co-authored-by: Dewi Roberts <dewi@goauthentik.io>
* first approach
* add cc and bcc support, better ui
* remove unnecessary data return
* add template support
* fix linting
* do the ui
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* display invite info in InvitationSendEmailForm.ts
* Select the invitation template by default
* Fix linting
* fix tests
* Add tests, clean code
* Add docs
* fix link
* Make the UI less disgusting
* Make the UI less disgusting
* Apply suggestions from code review
Co-authored-by: Dewi Roberts <dewi@goauthentik.io>
Signed-off-by: Marcelo Elizeche Landó <marce@melizeche.com>
* small formatting fix
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* Use writeToClipboard function, better wording for CC and BCC
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Marcelo Elizeche Landó <marce@melizeche.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Dewi Roberts <dewi@goauthentik.io>
* Add email_verified to komga
* Fix minor spelling issues in Komga docs.
* Add email scope verification link
* Update index.md
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
---------
Signed-off-by: Dewi Roberts <dewi@goauthentik.io>
Co-authored-by: dewi-tik <dewi@goauthentik.io>
* first draft
* add table of parms
* tweak
* add section about certs
* a little more content
* more info on wa
* new procedurla file and edit sidebar
* tweaks
* dewi and jens edits
* tweak to remove bullet
* add docs link to the Rel Notes
* dewi edits thx
* ooops missed that last edit
@@ -18,10 +18,10 @@ Even if the issue is not a CVE, we still greatly appreciate your help in hardeni
(.x being the latest patch release for each version)
| Version | Supported |
| --------- | --------- |
| 2025.12.x | ✅ |
| 2026.2.x | ✅ |
| Version | Supported |
| ---------- | ---------- |
| 2025.12.x | ✅ |
| 2026.2.x | ✅ |
## Reporting a Vulnerability
@@ -60,40 +60,6 @@ authentik reserves the right to reclassify CVSS as necessary. To determine sever
| 7.0 – 8.9 | High |
| 9.0 – 10.0 | Critical |
## Intended functionality
The following capabilities are part of intentional system design and should not be reported as security vulnerabilities:
- Expressions (property mappings/policies/prompts) can execute arbitrary Python code without safeguards.
This is expected behavior. Any user with permission to create or modify objects containing expression fields can write code that is executed within authentik. If a vulnerability allows a user without the required permissions to write or modify code and have it executed, that would be a valid security report.
However, the fact that expressions are executed as part of normal operations is not considered a privilege escalation or security vulnerability.
- Blueprints can access all files on the filesystem.
This access is intentional to allow legitimate configuration and deployment tasks. It does not represent a security problem by itself.
- Importing blueprints allows arbitrary modification of application objects.
This is intended functionality. This behavior reflects the privileged design of blueprint imports. It is "exploitable" when importing blueprints from untrusted sources without reviewing the blueprint beforehand. However, any method to create, modify or execute blueprints without the required permissions would be a valid security report.
- Flow imports may contain objects other than flows (such as policies, users, groups, etc.)
This is expected behavior as flow imports are blueprint files.
- Prompt HTML is not escaped.
Prompts intentionally allow raw HTML, including script tags, so they can be used to create interactive or customized user interface elements. Because of this, scripts within prompts may affect or interact with the surrounding page as designed.
- Open redirects that do not include tokens or other sensitive information are not considered a security vulnerability.
Redirects that only change navigation flow and do not expose session tokens, API keys, or other confidential data are considered acceptable and do not require reporting.
- Outgoing network requests are not filtered.
The destinations of outgoing network requests (HTTP, TCP, etc.) made by authentik to configurable endpoints through objects such as OAuth Sources, SSO Providers, and others are not validated. Depending on your threat model, these requests should be restricted at the network level using appropriate firewall or network policies.
## Disclosure process
1. Report from Github or Issue is reported via Email as listed above.
@@ -54,7 +54,7 @@ class TestEmailStageTemplates(FlowTestCase):
chmod(file2,0o000)# Remove all permissions so we can't read the file
choices=get_template_choices()
self.assertEqual(choices[-1][0],Path(file).name)
self.assertEqual(len(choices),5)
self.assertEqual(len(choices),6)
unlink(file)
unlink(file2)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
