afdf269869
**Summary:** Calls to _retrieve_, _create_, and _update_ Authenticators have been isolated into a module functions and code accessing those features have been revised to use those functions. **This commit** Isolates the Authenticators APIs for `authenticatorsAllList`, `authenticatorsAdminAllList`, `authenticators<Type>Destroy` and `authenticators<Type>Update` into a connector module, and updates client code to use them. This eliminates the duplication of `deleteAuthenticatorDevice`, the code for which was in both *Admin* and *User*, and creates a single source of truth for the DeviceType strings that identify Device subtypes. **Details** One thing that's bothered me a lot is the way our APIs, starting on the Django side, start with a base model and then "spread out" to incorporate many different inheritance models: different kinds of Providers, different kinds of Outposts, and different kinds of authentication devices. In a proper object-oriented system, we'd be granted access to the base class and have the power to use it effectively as a generic, switchboarding on some RTTI or value type to handle the differences between the concrete child types. The code generator we use does not provide that base model to UI clients; "funnelling down" to create a sort of artificial base class on the client and then fanning back out is an impractical and error-prone exercise. But we still do a lot of switchboarding, which has three problems: - Adding subtypes touches a lot of different code - Distant implementations can miss a specific instance of a subtype - Repeated use of strings as type handles can introduce spelling errors - The [last line effect](https://link.springer.com/article/10.1007/s10664-016-9489-6) can introduce new and subtle bugs when cut-and-pasting prior examples - Instances of the *same code* in multiple locations make for maintenance headaches This patch introduces the concept of **connectors**, modules that provide CRUD functions for common operations performed on objects of a specific subtype. It is *not* meant to replace concrete class displays or manipulations, such as (using providers as an example) `ProxyProviderViewPage` or HTML that is customized for a specific concrete type of provider. For retrieving lists, deleting instances that can be addressed from the base class, or updating objects — any place where which call among a collection of isomorphic APIs must be specifieda using `switch/case` statements — the connector provides a single source of truth for how to recognize the child types, which `switch/case` statements provide the utility, and what must be done to update them. |
||
|---|---|---|
| .. | ||
| .storybook | ||
| authentik/sources | ||
| icons | ||
| scripts | ||
| src | ||
| xliff | ||
| .babelrc | ||
| .dockerignore | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .eslintrc.precommit.json | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc.json | ||
| lit-localize.json | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| robots.txt | ||
| rollup.config.mjs | ||
| rollup.proxy.mjs | ||
| security.txt | ||
| static.go | ||
| static_outpost.go | ||
| tsconfig.json | ||
| web-test-runner.config.mjs | ||
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.
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.