* web: laying the groundwork for future expansion
This commit is a hodge-podge of updates and changes to the web. Functional changes:
- Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately
calculated if `help` was included rather than in-lined.
- ESLint: Modified the "unused vars" rule so that variables starting with an underline are not
considered by the rule. This allows for elided variables in event handlers. It's not a perfect
solution-- a better one would be to use Typescript's function-specialization typing, but there are
too many places where we elide or ignore some variables in a function's usage that switching over
to specialization would be a huge lift.
- locale: It turns out, lit-locale does its own context management. We don't need to have a context
at all in this space, and that's one less listener we need to attach t othe DOM.
- ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over
rendering and reduces the number of actual renders of the page.
- FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word
"Details." Specializing this field will both help users of screen readers in the future, and will
allow test suites to find specific form groups now.
- RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the
events to the outside world, and we set the value locally so that the current `Form.ts` continues
to behave as expected. We also prevent the "button lost value" event from propagating; this
presents a unified select-like interface to users of the RadioButtonGroup. The current value
semantics are preserved; other clients of the RadioButton do not see a change in behavior.
- EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics
for forwarding it; just send it as-is.
- Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of
comments into the code, describing APIs, interfaces, class and function signatures, to better
document the behavior inside and as signposts for future work.
* web: permit arrays to be sent in custom events without interpolation.
* actually use assignValue or rather serializeFieldRecursive
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: package up horizontal elements into their own components.
This commit introduces a number of "components." Jens has this idiom:
```
<ak-form-element-horizontal label=${msg("Name")} name="name" ?required=${true}>
<input
type="text"
value="${ifDefined(this.instance?.name)}"
class="pf-c-form-control"
required
/>
</ak-form-element-horizontal>
```
It's a very web-oriented idiom in that it's built out of two building blocks, the "element-horizontal" descriptor,
and the input object itself. This idiom is repeated a lot throughout the code. As an alternative, let's wrap
everything into an inheritable interface:
```
<ak-text-input
name="name"
label=${msg("Name")}
value="${ifDefined(this.instance?.name)}
required
>
</ak-text-input>
```
This preserves all the information of the above, makes it much clearer what kind of interaction we're having
(sometimes the `type=` information in an input is lost or easily missed), and while it does require you know
that there are provided components rather than the pair of layout-behavior as in the original it also gives
the developer more precision over the look and feel of the components.
*Right now* these components are placed into the LightDOM, as they are in the existing source code, because
the Form handler has a need to be able to "peer into" the "element-horizontal" component to find the values
of the input objects. In a future revision I hope to place the burden of type/value processing onto the
input objects themselves such that the form handler will need only look for the `.value` of the associated
input control.
Other fixes:
- update the FlowSearch() such that it actually emits an input event when its value changes.
- Disable the storybook shortcuts; on Chrome, at least, they get confused with simple inputs
- Fix an issue with precommit to not scan any Python with ESLint! :-)
* web: provide storybook stories for the components
This commit provides storybook stories for the ak-horizontal-element wrappers. A few
bugs were found along the way, including one rather nasty one from Radio where we
were still getting the "set/unset" pair in the wrong order, so I had to knuckle down
and fix the event handler properly.
* web: test oauth2 provider "guinea pig" for new components
I used the Oauth2 provider page as my experiment in seeing if the
horizontal-element wrappers could be used instead of the raw wrappers
themselves, and I wanted to make sure a test existed that asserts
that filling out THAT form in the ProvidersList and ProvidersForm
didn't break anything.
This commit updates the WDIO tests to do just that; the test is
simple, but it does exercise the `name` field of the Provider,
something not needed in the Wizard because it's set automatically
based on the Application name, and it even asserts that the new
Provider exists in the list of available Providers when it's done.
* web: making sure ESlint and Prettier are happy
* "fix" lint
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
* web: laying the groundwork for future expansion
This commit is a hodge-podge of updates and changes to the web. Functional changes:
- Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately
calculated if `help` was included rather than in-lined.
- ESLint: Modified the "unused vars" rule so that variables starting with an underline are not
considered by the rule. This allows for elided variables in event handlers. It's not a perfect
solution-- a better one would be to use Typescript's function-specialization typing, but there are
too many places where we elide or ignore some variables in a function's usage that switching over
to specialization would be a huge lift.
- locale: It turns out, lit-locale does its own context management. We don't need to have a context
at all in this space, and that's one less listener we need to attach t othe DOM.
- ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over
rendering and reduces the number of actual renders of the page.
- FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word
"Details." Specializing this field will both help users of screen readers in the future, and will
allow test suites to find specific form groups now.
- RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the
events to the outside world, and we set the value locally so that the current `Form.ts` continues
to behave as expected. We also prevent the "button lost value" event from propagating; this
presents a unified select-like interface to users of the RadioButtonGroup. The current value
semantics are preserved; other clients of the RadioButton do not see a change in behavior.
- EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics
for forwarding it; just send it as-is.
- Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of
comments into the code, describing APIs, interfaces, class and function signatures, to better
document the behavior inside and as signposts for future work.
* web: permit arrays to be sent in custom events without interpolation.
* actually use assignValue or rather serializeFieldRecursive
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
* core/allow alternative postgres credentials
This commit allows the `dev-reset` command in the Makefile to pick up and use credentials from the
`.env` file if they are present, or fallback to the defaults provided if they are not. This is the
only place in the Makefile where the database credentials are used directly against postgresql
binaries. The syntax was tested with bash, zsh, and csh, and did not fail under those.
The `$${:-}` syntax is a combination of a Makefile idiom for "Pass a single `$` to the environment
where this command will be executed," and the shell expresion `${VARIABLE:-default}` means
"dereference the environment variable; if it is undefined, used the default value provided."
* Re-arrange sequence to avoid recursive make.
Nothing wrong with recursive make; it just wasn't essential
here. `migrate` is just a build target, not a task.
* Cleanup according to the Usage:
checkmake [options] <makefile>...
checkmake -h | --help
checkmake --version
checkmake --list-rules Makefile linting tool.
* core: added 'help' to the Makefile
* get postgres config from authentik config loader
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* don't set -x by default
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* sort help
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* update help strings
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
remove default example stories that were broken
currently only the dark theme works due to the way storybook includes CSS files in the iframe
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: basic cleanup of buttons
This commit adds Storybook features to the Authentik four-stage button.
The four-stage button is used to:
- trigger an action
- show that the action is running
- show when the action has succeeded, then reset
- show when the action has failed, then reset
It is used mostly for fetching data from the server. The variants are:
- ak-spinner-button: The basic form takes a single property argument, `callAction` a function that
returns a Promise (an asynchronous function).
- ak-action-button: Takes an API request function (which are all asynchronous) and adapts it to the
`callAction`. The only difference in behavior with the Spinner button is that on failure the error
message will be displayed by a notification.
- ak-token-copy-button: A specialized button that, on success, pushes the content of the retrieved
object into the clipboard.
Cleanup consisted of:
- removing a lot of the in-line code from the HTML, decluttering it and making more explicit what
the behaviors of each button type are on success and on failure.
- Replacing the ad-hoc Promise management with Lit's own `Task` handler. The `Task` handler knows
how to notify a Lit-Element of its own internal state change, making it ideal for objects like
this button that need to change their appearance as a Promise'd task progresses from idle →
running → (success or failure).
- Providing JSDoc strings for all of the properties, slots, attributes, elements, and events.
- Adding 'pointer-events: none' during the running phases of the action, to prevent the user from
clicking the button multiple times and launching multiple queries.
- Emitting an event for every stage of the operation:
- `ak-button-click` when the button is clicked.
- `ak-button-success` when the action completes. The payload is included in `Event.detail.result`
- `ak-button-failure` when the action fails. The error message is included in `Event.detail.error`
- `ak-button-reset` when the button completes a notification and goes back to idle
**Storybook**
Since the API requests for both `ak-spinner-button` and `ak-action-button` require only that a
promise be returned, Storybooking them was straightforward. `ak-token-copy-button` is a
special-purpose derivative with an internal functionality that can't be easily mocked (yet), so
there's no Storybook for it.
All of the stories provide the required asynchronous function, in this cose one that waits three
seconds before emitting either a `response` or `reject` Promise.
`ak-action-button`'s Story has event handler code so that pressing on the button will result in a
message being written to a display block under the button.
I've added a new pair of class mixins, `CustomEmitterElement` and `CustomListenerElement`. These
each add an additional method to the classes they're mixed into; one provides a very easy way to
emit a custom event and one provides a way to receive the custom event while sweeping all of the
custom event type handling under the rug.
`emitCustomEvent` replaces this:
``` JavaScript
this.dispatchEvent(
new CustomEvent('ak-button-click', {
composed: true,
bubbles: true,
detail: {
target: this,
result: "Some result, huh?"
},
})
);
```
... with this:
``` JavaScript
this.dispatchCustomEvent('ak-button-click', { result: "Some result, huh?" });
```
The `CustomListenerElement` handler just ensures that the handler being passed to it takes a
CustomEvent, and then makes sure that any actual event passed to the handler has been type-guarded
to ensure it is a custom event.
**Observations**
*Composition vs Inheritance, Part 1*
The four-state button has three implementations. All three inherit from `BaseTaskButton`:
- `spinner`
- provides a default `callAction()`
- `action`
- provides a different name for `callAction`
- overrides `onError` to display a Notification.
- `token-copy`
- provides a custom `callAction`
- overrides `onSuccess` to copy the results to the keyboard
- overrides `onError` to display a Notification, with special handling for asynchronous
processing.
The *results* of all of these could be handled higher up as event handlers, and the button could be
just a thing that displays the states. As it is, the BaseStateToken has only one reason to change
(the Promise changes its state), so I'm satisfied that this is a suitable evolution of the product,
and that it does what it says it does.
*Developer Ergonomics*
The one thing that stands out to me time and again is just how *confusing* all of the Patternfly
stuff tends to be; not because it's not logical, but because it overwhelms the human 7±2 ability to
remember details like this without any imperative to memorize all of them. I would like to get them
under control by marshalling them under a semantic CSS regime, but I'm blocked by some basic
disconnects in the current development environment. We can't shake out the CSS as much as we'd like
because there's no ESPrima equivalent for Typescript, and the smallest bundle purgeCSS is capable of
making for just *one* button is about 55KB. That's a bit too much. It's a great system for getting
off the ground, but long-term it needs more love than we (can) give it.
* Prettier has opinions.
* Removed extraneous debugging code.
* Added comments to the BaseTaskButton parent class.
* web: fixed two build errors (typing) in the stories.
* web: prettier's got opinions
* web: refactor the buttons
This commit adds URL mocking to Storybook, which in turn allows us to
commit a Story for ak-token-copy-button.
I have confirmed that the button's algorithm for writing to the
clipboard works on Safari, Chrome, and Firefox. I don't know
what's up with IE.
* ONE BYTE in .storybook/main blocked integration.
With the repair of lit-analyze, it's time to fix the rule set
to at least let us pass for the moment.
* Still looking for the list of exceptions in lit-analyze that will let us pass once more.
* web: repair error in EnterpriseLicenseForm
This commit continues to find the right configuration for
lit-analyze. During the course of this repair, I discovered
a bug in the EnterpriseLicenseForm; the original usage could
result in the _string_ `undefined` being passed back as a
value. To handle the case where the value truly is undefined,
the `ifDefined()` directive must be used in the HTML template.
I have also instituted a case-by-case stylistic decision to allow
the HTML, and only the HTML, to be longer that 100 characters
when doing so reduces the visual "noise" of a function.
* ldap: support cert based auth
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* ldap: default sni switch to off
* ldap: `get_info=NONE` on insufficient access error
* fix: Make file locale script
* ldap: add google ldap attribute mappings
* ldap: move google secure ldap blueprint to examples
Revert "ldap: add google ldap attribute mappings"
This reverts commit 8a861bb92c1bd763b6e7ec0513f73b3039a1adb4.
* ldap: remove `validate` for client cert auth
not strictly necessary
* ldap: write temp cert files more securely
* ldap: use first array value for sni when provided csv input
* don't specify tempdir
we set $TMPDIR in the dockerfile
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* limit API to only allow certificate key pairs with private key
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* use maxsplit
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* update locale
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Jens L. <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
* api: add basic jwt support with required scope
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* api: only set auth_via when actually authenticating via token
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* save consented permissions in user consent, re-prompt when new permissions are required
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* update locale
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* translate special scope map
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* more api auth tests
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* add docs
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* build web api in e2e tests
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* link generated client instead of copying
Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>
* Improve clarity of dev environment setup doc
* Requested changes and further small improvements
* I actually read the makefile this time
* Add makefile entry for building ui
* Comments
* Add documentation setup
* Move documentation setup
* Formatting