28a23110c2
* 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.
* web: streamline CaptchaStage
# What
This commit:
1. Replaces the mass of `if () { if() { if() } }` with two state tables:
- One for `render()`
- One for `renderBody()`
2. Breaks each Captcha out into "interactive" and "executive" versions
3. Creates a handler table for each Captcha type
4. Replaces the `.forEach` expression with a `for` loop.
5. Move `updated` to the end of the class.
6. Make captchDocument and captchaFrame constructed-on-demand with a cache.
7. Remove a lot of `@state` handlers
8. Give IframeMessageEvent its own type.
9. Removed `this.scriptElement`
10. Replaced `window.removeEventListener` with an `AbortController()`
# Why
1. **Replacing `if` trees with a state table.** The logic of the original was really hard to follow.
With the state table, we can clearly see now that for the `render()` function, we care about the
Boolean flags `[embedded, challenged, interactive]` and have appropriate effects for each. With
`renderBody()`, we can see that we care about the Boolean flags `[hasError, challenged]`, and can
see the appropriate effects for each one.
2. (and 3.) **Breaking each Captcha clause into separate handlers.** Again, the logic was convoluted,
when what we really care about is "Does this captcha have a corresponding handler attached to
`window`, and, if so, should we run the interactive or executive version of it?" By putting all
of that into a table of `[name, challenge, execute]`, we can clearly see what's being handled
when.
4. **Replacing `foreach()` with `for()`**: [You cannot use a `forEach()` with async
expressions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach#:~:text=does%20not%20wait%20for%20promises).
If you need asynchronous behavior in an ordered loop, `for()` is the safest way to handle it; if
you need asynchronous behavior from multiple promises, `Promise.allSettled(handlers.map())` is
the way to go.
I tried to tell if this function *meant* to run every handler it found simultaneously, or if it
meant to test them in order; I went with the second option, breaking and exiting the loop once a
handler had run successfully.
5. **Reordered the code a bit**. We're trying to evolve a pattern in our source code: styles,
properties, states, internal variables, constructor, getters & setters that are not `@property()`
or `@state()`, DOM-related lifecycle handlers, event handlers, pre-render lifecycle handlers,
renderers, and post-render lifecycle handlers. Helper methods (including subrenderers) go above
the method(s) they help.
6. **Constructing Elements on demand with a cache**. It is not guaranteed that we will actually need
either of those. Constructing them on demand with a cache is both performant and cleaner.
Likewise, I removed these from the Lit object's `state()` table, since they're constructed once
and never change over the lifetime of an instance of `ak-stage-captcha`.
9. **Remove `this.scriptElement`**: It was never referenced outside the one function where it was used.
10. **Remove `removeEventListener()`**: `AbortController()` is a bit more verbose for small event
handler collections, but it's considered much more reliable and much cleaner.
* Didn't save the extracted ListenerController.
authentik WebUI
This is the default UI for the authentik server. The documentation is going to be a little sparse for awhile, but at least let's get started.
The Theory of the authentik UI
In Peter Naur's 1985 essay Programming as Theory Building, programming is described as creating a mental model of how a program should run, then writing the code to test if the program can run that way.
The mental model for the authentik UI is straightforward. There are five "applications" within the UI, each with its own base URL, router, and responsibilities, and each application needs as many as three contexts in which to run.
The three contexts corresponds to objects in the API's model section, so let's use those names.
- The root
Config. The root configuration object of the server, containing mostly caching and error reporting information. This is misleading, however; theConfigobject contains some user information, specifically a list of permissions the current user (or "no user") has. - The root
CurrentTenant. This describes theBrandinformation UIs should use, such as themes, logos, favicon, and specific default flows for logging in, logging out, and recovering a user password. - The current
SessionUser, the person logged in: username, display name, and various states. (Note: the authentik server permits administrators to "impersonate" any other user in order to debug their authentikation experience. If impersonation is active, theuserfield reflects that user, but it also includes a field,original, with the administrator's information.)
(There is a fourth context object, Version, but its use is limited to displaying version information and checking for upgrades. Just be aware that you will see it, but you will probably never interact with it.)
There are five applications. Two (loading and api-browser) are trivial applications whose
insides are provided by third-party libraries (Patternfly and Rapidoc, respectively). The other
three are actual applications. The descriptions below are wholly from the view of the user's
experience:
Flow: From a given URL, displays a form that requests information from the user to accomplish a task. Some tasks require the user to be logged in, but many (such as logging in itself!) obviously do not.User: Provides the user with access to the applications they can access, plus a few user settings.Admin: Provides someone with super-user permissions access to the administrative functions of the authentik server.
Mental Model
- Upon initialization, every authentik UI application fetches
ConfigandCurrentTenant.UserandAdminwill also attempt to load theSessionUser; if there is none, the user is kicked out to theFlowfor logging into authentik itself. Config,CurrentTenant, andSessionUser, are provided by the@goauthentik/apiapplication, not by the codebase under./web. (Where you are now).Flow,User, andAdminare all calledInterfacesand are found in./web/src/flow/FlowInterface,./web/src/user/UserInterface,./web/src/admin/AdminInterface, respectively.
Inside each of these you will find, in a hierarchal order:
- The context layer described above
- A theme managing layer
- The orchestration layer:
- web socket handler for server-generated events
- The router
- Individual routes for each vertical slice and its relationship to other objects:
Each slice corresponds to an object table on the server, and each slice usually consists of the following:
- A paginated collection display, usually using the
Tablefoundation (found in./web/src/elements/Table) - The ability to view an individual object from the collection, which you may be able to:
- Edit
- Delete
- A form for creating a new object
- Tabs showing that object's relationship to other objects
- Interactive elements for changing or deleting those relationships, or creating new ones.
- The ability to create new objects with which to have that relationship, if they're not part of the core objects (such as User->MFA authenticator apps, since the latter is not a "core" object and has no tab of its own).
We are still a bit "all over the place" with respect to sub-units and common units; there are
folders common, elements, and components, and ideally they would be:
common: non-UI related libraries all of our applications needelements: UI elements shared among multiple applications that do not need contextcomponents: UI elements shared among multiple that use one or more context
... but at the moment there are some context-sensitive elements, and some UI-related stuff in
common.
Comments
NOTE: The comments in this section are for specific changes to this repository that cannot be reliably documented any other way. For the most part, they contain comments related to custom settings in JSON files, which do not support comments.
tsconfig.json:compilerOptions.useDefineForClassFields: falseis required to make TSC use the "classic" form of field definition when compiling class definitions. Storybook does not handle the ESNext proposed definition mechanism (yet).compilerOptions.plugins.ts-lit-plugin.rules.no-unknown-tag-name: "off": required to support rapidoc, which exports its tag late.compilerOptions.plugins.ts-lit-plugin.rules.no-missing-import: "off": lit-analyzer currently does not support path aliases very well, and cannot find the definition files associated with imports using them.compilerOptions.plugins.ts-lit-plugin.rules.no-incompatible-type-binding: "warn": lit-analyzer does not support generics well when parsing a subtype ofHTMLElement. As a result, this threw too many errors to be supportable.
License
This code is licensed under the MIT License. A copy of the license is included with this package.