ade1f08c89
web: fix value handling inside controlled components (#9648) * 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: fix value handling inside controlled components This is one of those stupid bugs that drive web developers crazy. The basics are straightforward: when you cause a higher-level component to have a "big enough re-render," for some unknown definition of "big enough," it will re-render the sub-components. In traditional web interaction, those components should never be re-rendered while the user is interacting with the form, but in frameworks where there's dynamic re-arrangement, part or all of the form could get re-rendered at any mmoment. Since neither the form nor any of its intermediaries is tracking the values as they're changed, it's up to the components themselves to keep the user's input-- and to be hardened against property changes coming from the outside world. So static memoization of the initial value passed in, and aggressively walling off the values the customer generates from that field, are needed to protect the user's work from any framework's dynamic DOM management. I remember struggling with this in React; I had hoped Lit was better, but in this case, not better enough. The protocol for "is it an ak-data-control" is "it has a `json()` method that returns the data ready to be sent to the authentik server." I missed that in one place, so that's on me. * Eslint had opinions. * Added comments to explain something. Co-authored-by: Ken Sternberg <133134217+kensternberg-authentik@users.noreply.github.com>
What is authentik?
authentik is an open-source Identity Provider that emphasizes flexibility and versatility. It can be seamlessly integrated into existing environments to support new protocols. authentik is also a great solution for implementing sign-up, recovery, and other similar features in your application, saving you the hassle of dealing with them.
Installation
For small/test setups it is recommended to use Docker Compose; refer to the documentation.
For bigger setups, there is a Helm Chart here. This is documented here.
Screenshots
| Light | Dark |
|---|---|
 |
 |
 |
 |
Development
Security
See SECURITY.md
Adoption and Contributions
Your organization uses authentik? We'd love to add your logo to the readme and our website! Email us @ hello@goauthentik.io or open a GitHub Issue/PR! For more information on how to contribute to authentik, please refer to our CONTRIBUTING.md file.