* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* Just documenting current system and laying out intent.
* Moved the common block shared by flows and user/admin into a single declaration in the vendor section.
* Moved the copy/pasted overrides for login, form-control-static, and flow links into a separate file.
* ak-locale-select.css was imported twice, and then copy/pasted into a another file. Deduped.
* ak-locale-select.css was imported twice, and then copy/pasted into a another file. Deduped.
* Adjust the styling for FlowExecutor
This one has always bugged me, like it’s our trying to make the Flow page look exactly right. Which we absolutely should be doing! But figuring out how became archaelogy: layer upon layer of overrides, `!important` properties, and redirects.
What this does:
Separates the `login.css` into `login-tokens.css` (which has all the CSS Custom Properties) and `login-layout.css` (which has all the rules describing the FlowExecutor card layout.) These get concatenated into `static.global.css` to provide these values to the static pages, and via `FlowExecutor` to get these into the shadowDOM for that.
Adjusts `flows.global.css` to pull in the `flow-loading.css`, which has a pair of selectors that only apply in the browser state before Javascript has run (via `:not(:defined)`), to put the spinner where it belongs before the components begin doing their thing and having their own spinners and delay indicators.
Adjusts the layout so that only the CSS properties that affect the Flow *container* apply to the container. Funny, that. The `flex-flow` had no effect here. Instead, the Flow Executor now gets the layout and handles it internally and cleanly.
Consequently, FlowExecutor, which always took over the entire viewport anyway, doesn’t need the `.pf-c-login` styling; instead, since the Patterfly `Login/login.css` is pulled into FlowExecutor anyway, applying `.pf-c-login` it as a top-level wrapper to the shadowDOM template is what activates all the CSS custom properties for components after Javascript activation.
I ran this with both a “mid-tier mobile CPU” profile and a “slow 4G” profile and confirmed that, aside from our **very large** background taking *forever* to load in slow 4G, it looked the way I expected it to look, with no unstyled content.
We no longer have a circumstance where our global CSS pulls in FlowExecutor, which then turns around and pulls in the `login.css` file from out global CSS.
Did I mention how much I hate circular logic? Even if, in this case, it’s not a complete circle? But at least it’s not spaghetti anymore. Or, at least, not so much.
* Typo.
* Had to merge to route around a build bug; it's okay, prettier had opinions.
* A spelling error? In my code!? Inconceivable!
* This commit enables layers. It doesn’t do *anything* with them, mind you; CSS imports without `@layer` declarations always have higher specificity than anything else, so this is fine for our purposes at the moment. We are relying on this behavior so that the CSS *inside* our components has higher specificity than anything coming from the outside world. (Sadly, `::slotted()` is still the loser.)
The overall effect of this PR is that: nothing should change. It shouldn’t have any visual effect whatsoever. What is important is that, at this point, we are committing to using layers, we are relying on bundlers to get the ordering right for older browsers, and we are still in the process of hashing out what layers, and what names for the layers, we want to use going forward.
* Incorporate the patches for spacing the extra info zone.
* This commit enables layers. It doesn’t do *anything* with them, mind you; CSS imports without `@layer` declarations always have higher specificity than anything else, so this is fine for our purposes at the moment. We are relying on this behavior so that the CSS *inside* our components has higher specificity than anything coming from the outside world. (Sadly, `::slotted()` is still the loser.)
The overall effect of this PR is that: nothing should change. It shouldn’t have any visual effect whatsoever. What is important is that, at this point, we are committing to using layers, we are relying on bundlers to get the ordering right for older browsers, and we are still in the process of hashing out what layers, and what names for the layers, we want to use going forward.
* Globals, thematic elements (base ones, not very interesting), and icons are vendored.
* .
* Renamed and re-arranged the barrel files. Also: amnesia-oriented comments.
* Move all the vendor'd document files into the 'document' tree.
* Moved the base files into their own location, where the content lives for our shadowDOM.
* Moves the 'global' variables into their own layer. Moves the font _variables_ collection into variables; that's just part of the theme, it's not special and it shouldn't be treated as such. Yes, it refers to assets without which it looks broken, but the variable definitions are different from both the asset sources and the concrete usage.
* Moves the 'global' variables into their own layer. Moves the font _variables_ collection into variables; that's just part of the theme, it's not special and it shouldn't be treated as such. Yes, it refers to assets without which it looks broken, but the variable definitions are different from both the asset sources and the concrete usage.
* Moved the definitions around a bit.
* web/css: Continue the re-arrangement and organization of styles
The entrypoint files don’t need to be named `.global`; they’re not technically globals, they’re entrypoints. By dictating the root of the `styles` folder contains only the `layers.css` declaration and then using those layers in the entrypoint files, we isolate “what goes where” to a single starting point.
* Revert "web/css: Continue the re-arrangement and organization of styles"
This reverts commit 3ffc202a55.
* Reapply "web/css: Continue the re-arrangement and organization of styles"
This reverts commit f08fd86283.
* Turns out, the '.global' tag is needed to trigger the correct referencing behavior.
* Added a lot of comments; build not currently broken.
* Disambiguating pass: folders match layer names. theme -> mode, global -> theme
* Disambiguating pass: folders match layer names. theme -> mode, global -> theme
* web/css: Continue the re-arrangement and organization of styles
This commit disassembles “common.css,” which was a grab-bag of modifiers, component overrides and mode definitions. The component parts were given their own sections in `authentik/components`, the modifiers were (inelegantly) put into `authentik/components/modifiers`, the dark-mode stuff was put into `mode/mode.css`, and the high-contrast stuff put into `mode/contrast.css`. They were then codified into what layers they belonged. In some cases, where only one to three web components used them, references to inner element overrides were provided directly to the component; otherwise, they were (again, inelegantly) shoved into `authentik-base.css`.
* Missed one: Screenreader.
* Globals, thematic elements (base ones, not very interesting), and icons are vendored.
* .
* Renamed and re-arranged the barrel files. Also: amnesia-oriented comments.
* Move all the vendor'd document files into the 'document' tree.
* Moved the base files into their own location, where the content lives for our shadowDOM.
* Moves the 'global' variables into their own layer. Moves the font _variables_ collection into variables; that's just part of the theme, it's not special and it shouldn't be treated as such. Yes, it refers to assets without which it looks broken, but the variable definitions are different from both the asset sources and the concrete usage.
* Moves the 'global' variables into their own layer. Moves the font _variables_ collection into variables; that's just part of the theme, it's not special and it shouldn't be treated as such. Yes, it refers to assets without which it looks broken, but the variable definitions are different from both the asset sources and the concrete usage.
* Moved the definitions around a bit.
* web/css: Continue the re-arrangement and organization of styles
The entrypoint files don’t need to be named `.global`; they’re not technically globals, they’re entrypoints. By dictating the root of the `styles` folder contains only the `layers.css` declaration and then using those layers in the entrypoint files, we isolate “what goes where” to a single starting point.
* Revert "web/css: Continue the re-arrangement and organization of styles"
This reverts commit 3ffc202a55.
* Reapply "web/css: Continue the re-arrangement and organization of styles"
This reverts commit f08fd86283.
* Turns out, the '.global' tag is needed to trigger the correct referencing behavior.
* Added a lot of comments; build not currently broken.
* Disambiguating pass: folders match layer names. theme -> mode, global -> theme
* Disambiguating pass: folders match layer names. theme -> mode, global -> theme
* web/css: Continue the re-arrangement and organization of styles
This commit disassembles “common.css,” which was a grab-bag of modifiers, component overrides and mode definitions. The component parts were given their own sections in `authentik/components`, the modifiers were (inelegantly) put into `authentik/components/modifiers`, the dark-mode stuff was put into `mode/mode.css`, and the high-contrast stuff put into `mode/contrast.css`. They were then codified into what layers they belonged. In some cases, where only one to three web components used them, references to inner element overrides were provided directly to the component; otherwise, they were (again, inelegantly) shoved into `authentik-base.css`.
* Missed one: Screenreader.
* Adjust the storybook layers. Can't believe I almost forgot that. Moved the storybook overrides *into* the storybook configuration.
* web/css: moved the contents of 'color-dark' to mode.css
* Fixed typo: Only an extraordinary reason justifies a Patternfly file being anything other than 'vendor'; noted that we don't have a 'reduced-motion' setting yet.
* Added the README.
* Embarassing spelling error.
* Noticed the README wasn't the way I wanted it.
* Needed to add 'FOUC' to the spellcheck. Also, a comment about UK spelling no longer made sense in context, so I re-arranged them a bit so that it did.
* Somehow this missed the merge.
* Typos suck.
* Spelling errors!? In my code? It's more likely than you think!
* ## What
window.authentik.flow = {
"layout": "{{ flow.layout }}",
+ "background": "{{ flow.background }}",
+ "title": "{{ flow.title }}",
};
Amends the `flow.html` template and `GlobalAuthentik` parser to include new parameters, `background` and `title`, in the flow-specific part of the configuration written to the HTML `<head>` object, and to provide those parameters to client code.
## Why
The `layout` is start-up critical: it tells the Flow interface how the admin wants the Flow page to look, and allows the HTML and CSS to be pre-aligned to that condition. `layout` is determined on a per-Flow bases, not a per-Stage basis; Flows are derived from a tuple of `(Brand, Application?)`, where the opening policy *may* direct a user to a different flow if the user reached authentik via a redirect from a specific application, but will otherwise fall back to the default Flow for the Brand.
The `background` is a field that is required if the `Flow`’s layout is of type `frame_background`; in this case, the part of the viewport not dedicated to the FlowExecutor is reserved for an `<iframe>` that will be filled in with whatever the administrator specifies. Although this gives it the same priority as `layout` (whether it’s provided or undefined) for describing the [chrome](https://developer.mozilla.org/en-US/docs/Glossary/Chrome) around a challenge, it is currently not provided to the application in the start-up config; it is provided in the `challenge` and renders the IFrame as part of the initial challenge.
This patch fixes that; if `layout` is provided, `background` ought to be as well, even if it’s empty. The execution of a Challenge ought not have any influence over the look and feel of the Flow-defined appearance *around* that Challenge.
I have added `title` as well; with that, all of the current theme-and-appearance related configuration details are placed into `<head>` and can be removed from the FlowExecutor.
Server-side, `background` is currently specified: `background = FileField(blank=True, default="")` which is … interesting since we also appear to store URLs in it. I don’t see anything in the FlowSerializer that would change that from a client’s point of view.
This patch furthers the effort to separate flow execution from flow presentation.
- \[🐰\] The code has been formatted (`make web`)
* Just documenting current system and laying out intent.
* Moved the common block shared by flows and user/admin into a single declaration in the vendor section.
* Moved the copy/pasted overrides for login, form-control-static, and flow links into a separate file.
* ak-locale-select.css was imported twice, and then copy/pasted into a another file. Deduped.
* ak-locale-select.css was imported twice, and then copy/pasted into a another file. Deduped.
* Adjust the styling for FlowExecutor
This one has always bugged me, like it’s our trying to make the Flow page look exactly right. Which we absolutely should be doing! But figuring out how became archaelogy: layer upon layer of overrides, `!important` properties, and redirects.
What this does:
Separates the `login.css` into `login-tokens.css` (which has all the CSS Custom Properties) and `login-layout.css` (which has all the rules describing the FlowExecutor card layout.) These get concatenated into `static.global.css` to provide these values to the static pages, and via `FlowExecutor` to get these into the shadowDOM for that.
Adjusts `flows.global.css` to pull in the `flow-loading.css`, which has a pair of selectors that only apply in the browser state before Javascript has run (via `:not(:defined)`), to put the spinner where it belongs before the components begin doing their thing and having their own spinners and delay indicators.
Adjusts the layout so that only the CSS properties that affect the Flow *container* apply to the container. Funny, that. The `flex-flow` had no effect here. Instead, the Flow Executor now gets the layout and handles it internally and cleanly.
Consequently, FlowExecutor, which always took over the entire viewport anyway, doesn’t need the `.pf-c-login` styling; instead, since the Patterfly `Login/login.css` is pulled into FlowExecutor anyway, applying `.pf-c-login` it as a top-level wrapper to the shadowDOM template is what activates all the CSS custom properties for components after Javascript activation.
I ran this with both a “mid-tier mobile CPU” profile and a “slow 4G” profile and confirmed that, aside from our **very large** background taking *forever* to load in slow 4G, it looked the way I expected it to look, with no unstyled content.
We no longer have a circumstance where our global CSS pulls in FlowExecutor, which then turns around and pulls in the `login.css` file from out global CSS.
Did I mention how much I hate circular logic? Even if, in this case, it’s not a complete circle? But at least it’s not spaghetti anymore. Or, at least, not so much.
* Typo.
* Had to merge to route around a build bug; it's okay, prettier had opinions.
* A spelling error? In my code!? Inconceivable!
* Incorporate the patches for spacing the extra info zone.
* Needed to add 'FOUC' to the spellcheck. Also, a comment about UK spelling no longer made sense in context, so I re-arranged them a bit so that it did.
* Replace npm + Corepack with pnpm
Migrate package management from npm + Corepack to pnpm across the root,
web, and website workspaces:
- Swap npm/Corepack tooling for pnpm: drop package-lock.json files and the
bespoke Corepack bootstrap scripts (setup-corepack.mjs, utils/corepack.mjs,
lint-lockfile.mjs); add pnpm-lock.yaml + pnpm-workspace.yaml per workspace.
- CI uses the official pnpm/action-setup + actions/setup-node; pin the pnpm
store dir via PNPM_HOME so setup-node's `cache: pnpm` post-step succeeds.
- Docker sources pnpm from the official ghcr.io/pnpm/pnpm image via a
${BUILDPLATFORM}-pinned stage; the website docs build does a hoisted root
install so @goauthentik/docusaurus-config resolves its own deps.
- Gate the web install on the `node` dep so runtime-only jobs don't invoke
pnpm; scope the from-stable env setup so the new tooling doesn't run against
the stable checkout's npm packageManager field.
- Resolve @goauthentik/api (client-ts) from its TypeScript source instead of a
tsc-built dist, so it no longer depends on an install-time prepare having run
(the storybook build's environment never built it); sfe's rollup gains .ts
resolution to match.
- Netlify builds with pnpm; encode pnpm's supply-chain controls
(onlyBuiltDependencies/allowBuilds, minimumReleaseAge) in the workspace.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Remove custom node action.
* Format.
cspell's bundled en_US dictionary accepts British spellings (colour, behaviour, organise, ...) even with language en-US. Add a flagWords list covering the common -our/-ise/-yse/-re/-ce families so they are reported as forbidden words with the American spelling offered as a fix, plus ignore entries for upstream-spelled exceptions (PatternFly pf-m-grey, lit-analyse, analyse-phase).
MERGE LAST: failFast is on, so this rule must land only after the docs/backend/frontend cleanup PRs have merged, otherwise CI fails on pre-existing British spellings.
Co-authored-by: Playpen Agent <279763771+playpen-agent@users.noreply.github.com>
