* 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.
* web: Update to OpenAPI 7.11.
This commit updates our Makefile to generate the Typescript api using OpenAPI 7.11, and updates
names (mostly of enum targets) in our product to correspond to the changes in how OpenAPI generates
enum source names.
1. Replaced `ProviderModelEnum.` (note terminal period) with `ProviderModelEnum.AuthentikProvider`.
For example:
```
- ProviderModelEnum.SamlSamlprovider
+ ProviderModelEnum.AuthentikProvidersSamlSamlprovider
```
2. Replaced `RbacPermissionsAssignedByUsersListModelEnum.` (note terminal period) with
`RbacPermissionsAssignedByUsersListModelEnum.Authentik`. For example:
```
- RbacPermissionsAssignedByUsersListModelEnum.ProvidersLdapLdapprovider.toString(),
+ RbacPermissionsAssignedByUsersListModelEnum.AuthentikProvidersLdapLdapprovider.toString(),
```
3. Replaced `SyncObjectModelEnum.` (note terminal period) with
`SyncObjectModelEnum.AuthentikCoreModels`. For example:
```
- model=${SyncObjectModelEnum.Group}
+ model=${SyncObjectModelEnum.AuthentikCoreModelsGroup}
```
4. Replaced `SignatureAlgorithmEnum._` (note terminal symbols) with
`SignatureAlgorithmEnum.HttpWwwW3Org`. For example:
```
- ["ECDSA-SHA256", SignatureAlgorithmEnum._200104XmldsigMoreecdsaSha256],
+ ["ECDSA-SHA256", SignatureAlgorithmEnum.HttpWwwW3Org200104XmldsigMoreecdsaSha256],
```
5. Replaced `DigestAlgorithmEnum._` (note terminal symbols) with `DigestAlgorithmEnum.HttpWwwW3Org`.
For example:
```
- ["SHA256", DigestAlgorithmEnum._200104Xmlencsha256, true],
+ ["SHA256", DigestAlgorithmEnum.HttpWwwW3Org200104Xmlencsha256, true],
```
6. Replaced `NameIdPolicyEnum._` (note terminal symbols) with
`NameIdPolicyEnum.UrnOasisNamesTcSaml`. This one is trickier than the others: If you look
closely, you'll see that how OpenAPI generates the names has changed, with `nameid` now being
`Nameid`, and `FormatemailAddress` now being `FormatEmailAddress`.
```
- value=${NameIdPolicyEnum._11nameidFormatemailAddress}
+ value=${NameIdPolicyEnum.UrnOasisNamesTcSaml11NameidFormatEmailAddress}
```
# How
After determining how the enum prefixes had changed, I just ran six of these, testing after each
step to ensure that `npm run lint:types` had fewer errors than the previous run, until the product
built without type errors.
``` sh
$ perl -pi.bak -e 's/DigestAlgorithmEnum\._/DigestAlgorithmEnum.HttpWwwW3Org/' $(rg -l 'DigestAlgorithmEnum\.' src/)
```
# Testing
You can validate that these items have changed by finding the prefixes in the source code and
assuring yourself that every option, checkbox, or radio associated with them is populated correctly.
# User documentation changes required.
None.
# Developer documentation changes required.
None.
* web: fix esbuild issue with style sheets
Getting ESBuild, Lit, and Storybook to all agree on how to read and parse stylesheets is a serious
pain. This fix better identifies the value types (instances) being passed from various sources in
the repo to the three *different* kinds of style processors we're using (the native one, the
polyfill one, and whatever the heck Storybook does internally).
Falling back to using older CSS instantiating techniques one era at a time seems to do the trick.
It's ugly, but in the face of the aggressive styling we use to avoid Flashes of Unstyled Content
(FLoUC), it's the logic with which we're left.
In standard mode, the following warning appears on the console when running a Flow:
```
Autofocus processing was blocked because a document already has a focused element.
```
In compatibility mode, the following **error** appears on the console when running a Flow:
```
crawler-inject.js:1106 Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
at initDomMutationObservers (crawler-inject.js:1106:18)
at crawler-inject.js:1114:24
at Array.forEach (<anonymous>)
at initDomMutationObservers (crawler-inject.js:1114:10)
at crawler-inject.js:1549:1
initDomMutationObservers @ crawler-inject.js:1106
(anonymous) @ crawler-inject.js:1114
initDomMutationObservers @ crawler-inject.js:1114
(anonymous) @ crawler-inject.js:1549
```
Despite this error, nothing seems to be broken and flows work as anticipated.
* web: add more linting
* A reliable test for the extra code needed in analyzer, passing shellcheck
* web: re-enable custom-element-manifest and enable component checking in Typescript
This commit includes a monkeypatch to allow custom-element-manifest (CEM) to work correctly again
despite our rich collection of mixins, reactive controllers, symbol-oriented event handlers, and the
like. With that monkeypatch in place, we can now create the CEM manifest file and then exploit it so
that IDEs and the Typescript compilation pass can tell when a component is being used incorrectly;
when the wrong types are being passed to it, or when a required attribute is not initialized.
* Added building the manifest to the build process, rather than storing it. It is not appreciably slow.
* web: the most boring PR in the universe: Add HTMLTagNameElementMap to everyhing
This commit adds HTMLTagNameElementMap entries to every web component in the front end. Activating
and associating the HTMLTagNamElementMap with its class has enabled
[LitAnalyzer](https://github.com/runem/lit-analyzer/tree/master/packages/lit-analyzer) to reveal a
*lot* of basic problems within the UI, the most popular of which is "missing import." We usually get
away with it because the object being imported was already registered with the browser elsewhere,
but it still surprises me that we haven't gotten any complaints over things like:
```
./src/flow/stages/base.ts
Missing import for <ak-form-static>
96: <ak-form-static
no-missing-import
```
Given how early and fundamental that seems to be in our code, I'd have expected to hear _something_
about it.
I have not enabled most of the possible checks because, well, there are just a ton of warnings when
I do. I'd like to get in and fix those.
Aside from this, I have also _removed_ `customElement` declarations from anything declared as an
`abstract class`. It makes no sense to try and instantiate something that cannot, by definition, be
instantiated. If the class is capable of running on its own, it's not abstract, it just needs to be
overridden in child classes. Before removing the declaration I did check to make sure no other
piece of code was even *trying* to instantiate it, and so far I have detected no failures. Those
elements were:
- elements/forms/Form.ts
- element-/wizard/WizardFormPage.ts
The one that blows my mind, though, is this:
```
src/elements/forms/ProxyForm.ts
6-@customElement("ak-proxy-form")
7:export abstract class ProxyForm extends Form<unknown> {
```
Which, despite being `abstract`, is somehow instantiable?
```
src/admin/outposts/ServiceConnectionListPage.ts: <ak-proxy-form
src/admin/providers/ProviderListPage.ts: <ak-proxy-form
src/admin/sources/SourceWizard.ts: <ak-proxy-form
src/admin/sources/SourceListPage.ts: <ak-proxy-form
src/admin/providers/ProviderWizard.ts: <ak-proxy-form type=${type.component}></ak-proxy-form>
src/admin/stages/StageListPage.ts: <ak-proxy-form
```
I've made a note to investigate.
I've started a new folder where all of my one-off tools for *how* a certain PR was run. It has a
README describing what it's for, and the first tool, `add-htmlelementtagnamemaps-to-everything`, is
its first entry. That tool is also documented internally.
``` Gilbert & Sullivan
I've got a little list,
I've got a little list,
Of all the code that would never be missed,
The duplicate code of cute-and-paste,
The weak abstractions that lead to waste,
The embedded templates-- you get the gist,
There ain't none of 'em that will ever be missed,
And that's why I've got them on my list!
```
* web: fix esbuild issue with style sheets
Getting ESBuild, Lit, and Storybook to all agree on how to read and parse stylesheets is a serious
pain. This fix better identifies the value types (instances) being passed from various sources in
the repo to the three *different* kinds of style processors we're using (the native one, the
polyfill one, and whatever the heck Storybook does internally).
Falling back to using older CSS instantiating techniques one era at a time seems to do the trick.
It's ugly, but in the face of the aggressive styling we use to avoid Flashes of Unstyled Content
(FLoUC), it's the logic with which we're left.
In standard mode, the following warning appears on the console when running a Flow:
```
Autofocus processing was blocked because a document already has a focused element.
```
In compatibility mode, the following **error** appears on the console when running a Flow:
```
crawler-inject.js:1106 Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
at initDomMutationObservers (crawler-inject.js:1106:18)
at crawler-inject.js:1114:24
at Array.forEach (<anonymous>)
at initDomMutationObservers (crawler-inject.js:1114:10)
at crawler-inject.js:1549:1
initDomMutationObservers @ crawler-inject.js:1106
(anonymous) @ crawler-inject.js:1114
initDomMutationObservers @ crawler-inject.js:1114
(anonymous) @ crawler-inject.js:1549
```
Despite this error, nothing seems to be broken and flows work as anticipated.
* Intermediate; prepping for remove that may fail.
* web: provide a default table endpoint configuration
This commit finds 19 places where the exact same configuration is
used to describe a table's API endpoint, and replaces that configuration
with a provided default from a parent class.
While examining the logs for our build, I noted that this particular
sequence is duplicated multiple times throughout our code base,
accounting for a bloat of 169 lines or so of the estimated 5552
lines of bloat. By providing a default endpoint configuration and
substituting it (mechanically) wherever the default is required,
we reduce our code duplication issue from 9.26% of the codesabe
to 8.99%.
... which is a start.
* Didn't need the duplication.
* remove page argument while we're at it
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* actually use it everywhere
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: fix inconsistent method signature for LogViewer
Removed the `_page` parameter from LogViewer's apiEndpoint() method.
The `page: number` parameter is no longer a part of this method's signature.
* web: restore reduced page size to Overview:Recent Events card
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
