2ba66f4f91
* Holding for a moment...
* web: replace rollup with esbuild
This commit replaces rollup with esbuild.
The biggest fix was to alter the way CSS is imported into our system;
esbuild delivers it to the browser as text, rather than as a bundle
with metadata that, frankly, we never use. ESBuild will bundle the
CSS for us just fine, and interpreting those strings *as* CSS turned
out to be a small hurdle. Code has been added to AKElement and
Interface to ensure that all CSS referenced by an element has been
converted to a Browser CSSStyleSheet before being presented to the
browser.
A similar fix has been provided for the markdown imports. The
biggest headache there was that the re-arrangement of our documentation
broke Jen's existing parser for fixing relative links. I've provided
a corresponding hack that provides the necessary detail, but since
the Markdown is being presented to the browser as text, we have to
provide a hint in the markdown component for where any relative
links should go, and we're importing and processing the markdown
at runtime. This doesn't seem to be a big performance hit.
The entire build process is driven by the new build script, `build.mjs`,
which starts the esbuild process as a service connected to the build
script and then runs the commands sent to it as fast as possible.
The biggest "hack" in it is actually the replacement for rollup's
`rollup-copy-plugin`, which is clever enough I'm surprised it doesn't
exist as a standalone file-copy package in its own right.
I've also used a filesystem watch library to encode a "watcher"
mechanism into the build script. `node build.mjs --watch` will
work on MacOS; I haven't tested it elsewhere, at least not yet.
`node build.mjs --proxy` does what the old rollup.proxy.js script
did.
The savings are substantial. It takes less than two seconds to build
the whole UI, a huge savings off the older ~45-50 seconds I routinely
saw on my old Mac. It's also about 9% smaller.
The trade-offs appear to be small: processing the CSS as StyleSheets,
and the Markdown as HTML, at run-time is a small performance hit,
but I didn't notice it in amongst everything else the UI does as
it starts up.
Manual chunking is gone; esbuild's support for that is quite difficult
to get right compared to Rollup's, although there's been a bit of
yelling at ESbuild over it. Codemirror is built into its own chunk;
it's just not _named_ distinctly anymore.
The one thing I haven't been able to test yet is whether or not the
polyfills and runtim shims work as expected on older browsers.
* web: continue with performance and build fixes
This commit introduces a couple of fixes enabled by esbuild and other
features.
1. build-locales
`build-locales` is a new NodeJS script in the `./scripts` folder
that does pretty much what it says in the name: it translates Xliff
files into `.ts` files. It has two DevExp advantages over the old
build system.
First, it will check the build times of the xlf files and
their ts equivalents, and will only run the actual build-locales
command if the XLF files are newer than their TS equivalents.
Second, it captures the stderr output from the build-locales command
and summarizes it. Instead of the thousands of lines of "this
string has no translation equivalent," now it just reports the
number of missed translations per locale.
2. check-spelling
This is a simple wrapper around the `codespell` command, mostly
just to reduce the visual clutter of `package.json`, but also to
permit it to run just about anywhere without needed hard-coded
paths to the dictionaries, using a fairly classic trick with git.
3. pseudolocalize and import-maps
These scripts were in TypeScript, but for our purposes I've
saved their constructed equivalents instead. This saves on
visual clutter in the `package.json` script, and reduced the
time they have to run during full builds. They're small enough
I feel confident they won't need too much looking over.
Also, two lint bugs in Markdown.ts have been fixed.
* Removed a few lines that weren't in use.
* build-locales was sufficiently complex it needed some comments.
* web: formalize that horrible unixy git status checker into a proper function.
* Added types for , the Markdown processor for in-line documentation.
* web: upgrade to Lit3
This commit replaces our Lit2 implementation with a Lit3 implementation.
This upgrade required two major shifts within our code, both of them consequential.
First, the restructuring of the way the get/set decorators for properties and states meant that a
lot of the code we were using needed to be refactored. More than that, a lot of those custom
accessors were implemented to trigger side-effects, such as when a providerID is set or changed
triggering the ProviderView to fetch the requsted Provider. The Lit2 and Lit3 documentation both say
[there is a better way to handle
this](https://lit.dev/docs/v2/components/properties/#:~:text=In%20most%20cases%2C%20you%20do%20not%20need%20to%20create%20custom%20property%20accessors)
by detecting the change in the `willUpdate()` point of an elements Lifecycle and triggering the side
effect there instead. I've done this in several places with a pattern of detecting the change, and
then naming the corresponding change as `fetchRequestedThing()`. The resulting code is cleaner and
uses fewer controversial features.
The other is that the type signature for `LitElement.createRenderRoot()` has changed to be either an
HTMLElement or a DocumentFragment. This required some serious refactoring of type changes through
Base and Interface codes. Noteably, the custom `AdoptedStyleSheetsElement` interface has been
superseded by the supplied and standardized
[DocumentOrShadowRoot](aa2b2352e1/src/lib/dom.generated.d.ts (L4715))
interface. Unfortunately, that interface is a mixin, and casting or instance checking are still in
place to make sure the objects being manipulated are typed "correctly."
Three files I touched during the course of this triggered SonarJS, so there are some minor fixes,
replacing some awkward syntax with more idiomatic code. These are very minor, such as replacing:
```
const result = someFunction();
return result;
/* with */
return someFunction();
```
and
```
const result = x();
if (!result) { return true } else { return false }
/* with */
return !x();
```
* fix package lock
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* don't use hardcoded magic values
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
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.