* make connection objects not updatable but allow creating with provider
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* save data returned from google/entra and show it in UI
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* pass connection object
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* set immutable id on user automatically
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* better define transient error codes
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* format
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix entra
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* 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.
* 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: clean up a bit inside the promptform
Just something I did while researching Github Issue 5197.
* 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: clean up some repetitive types
This commit centralizes two types that were defined multiple times throughout our code, and
casts in stone those definitions, applying the correct definitions where needed.
I had two types that were used repeatedly to define the interfaces for providers and context
consumers. Because they were both one-liners, I had done what I usually curse in others: copied
them. Worse, I hand-wrote them because they're so simple I had them memorized.
* 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: markdown: display markdown even when frontmatter is missing
Make the check for the document title comprehensive across the
entire demeter. If there is no front matter, `data` will be missing,
not just `data.title`.
* 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 locale prioritization scheme
The locale priority algorithm had two problems: first, the order was incorrect, allowing the global
default from globalAK() to override a lot of more precise settings; second, the algorithm would take
outside locale overrides from the event handler, which was not necessary.
This commit revises the locale prioritization scheme. It continues to watch for "change of locale"
events from all sources (URL, browser, and user/brand/site internal settings), but if the event
carries a suggested locale, that suggestion is ignored. Instead, when a change of locale event
occurs, it re-runs the algorithm in priority order.
That order is:
- The URL query parameter `locale=`
- The User's stated preference in `CurrentUser.attributes`
- The Browser's stated locale
- The Brand's stated preference in `CurrentBrand.attributes`
- The authentik instance's setting `from window.globalAK()`
- The default locale complied into the UI at build time.
Note to @tanberry: We should note this order somewhere in the documentation, so that users are not
"surprised" that their user preference (set in User Interface -> Settings -> User Details -> Locale)
is not overriden by the browser's preference. (The setting they need is "Based on your browser" to
make browser locale detection work.)
* web: fix locale prioritization scheme
The locale priority algorithm had two problems: first, the order was incorrect, allowing the global
default from globalAK() to override a lot of more precise settings; second, the algorithm would take
outside locale overrides from the event handler, which was not necessary.
This commit revises the locale prioritization scheme. It continues to watch for "change of locale"
events from all sources (URL, browser, and user/brand/site internal settings), but if the event
carries a suggested locale, that suggestion is ignored. Instead, when a change of locale event
occurs, it re-runs the algorithm in priority order.
That order is:
- The URL query parameter `locale=`
- The User's stated preference in `CurrentUser.attributes`
- The Browser's stated locale
- The Brand's stated preference in `CurrentBrand.attributes`
- The authentik instance's setting `from window.globalAK()`
- The default locale complied into the UI at build time.
Note to @tanberry: We should note this order somewhere in the documentation, so that users are not
"surprised" that their user preference (set in User Interface -> Settings -> User Details -> Locale)
is not overriden by the browser's preference. (The setting they need is "Based on your browser" to
make browser locale detection work.)
* web: locale patch for currentUser.settings
Temporarily skipping currentUser.settings.locale as a source of
truth because it's not portable between User/Admin and Flow; Flow
in a logged-out state has no access to `/me`, but we need to probe
`/me` for user settings. This conflict currently triggers a bug
in the session heartbeat handler.
* 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: manage stacked modals with a stack
"Events flow up. Instructions flow down."
This commit creates a top-level listening controller associated with the main
Interface that listens for ModalShow events and registers the modal with a
stack. When it receives a corresponding KeyUp:Escape, it closes the topmost
modal and removes all references to that modal from the stack. When it receives
a ModalHide event, it removes all references to the target modal and removes all
references to that modal from the stack.
This commit includes a few new techniques. First, thanks to Justin Fagnani and
the Shoelace team, this commit includes an alternative technique for declaring
custom events by leveraging the GlobalEventHandlers type. This actually works
better: the event is explicit, easy to understand, and the typescript language
server actually gets them to correspond correctly; if you listen for a specific
custom event, the handler had better be of the right type to receive that
specific event!
Second, this introduces the first custom decorator, @bound(), which eliminates
the need to say `this.eventHandler = this.eventHandler.bind(this)` from event
handling methods that will have to be passed outside the `this` context of an
HTMLElement. After conducting several experiments to see if I understood the
PropertyDescriptor protocol correctly, I conclud that this is a safe technique
for wiring up `removeEventListener()` handlers.
* Prettier had opinions.
* web: manage stacked modals with a stack
By reviewer request, the `.closeModal()` protocol has been updated
so that if the method returns `false` (explicitly; `undefined` is
not `false`!), the `.closeModal()` protocol is aborted, the modal
remains at the top of the stack, and cleanup is not initiated.
Modal forms can now have an "are you sure?" pass if the user triggers
a close without saving the form. Figuring out how to close *two*
modals if the user *is* sure, and making the Form modal return `true`
when the user *is* sure, are left for a future exercise. :-)
* web: fix stack handling bug for `Escape`, and make Lint happier about loops
