* main:
web: package up horizontal elements into their own components (#7053)
core: bump django from 4.2.5 to 4.2.6 (#7066)
translate: Updates for file locale/en/LC_MESSAGES/django.po in fr on branch main (#7065)
web: bump postcss from 8.4.29 to 8.4.31 in /web (#7064)
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh-Hans on branch main (#7057)
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh_CN on branch main (#7056)
web: bump pyright from 1.1.329 to 1.1.330 in /web (#7060)
web: bump the storybook group in /web with 5 updates (#7059)
web: bump the wdio group in /tests/wdio with 2 updates (#7063)
core: bump duo-client from 5.0.1 to 5.1.0 (#7062)
core: bump goauthentik.io/api/v3 from 3.2023083.3 to 3.2023083.4 (#7061)
Add meta description to black box blog post (#7049)
web/flows: fix plex login not opening new tab on mobile safari (#7050)
web: bump API Client version (#7052)
web/flows: bottom-align about text on flows page (#7051)
core: bump codespell from 2.2.5 to 2.2.6 (#7046)
core: bump coverage from 7.3.1 to 7.3.2 (#7047)
web: laying the groundwork for future expansion (#7045)
* 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>
* main:
core: bump urllib3 from 2.0.5 to 2.0.6 (#7042)
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh_CN on branch main (#7043)
translate: Updates for file locale/en/LC_MESSAGES/django.po in zh-Hans on branch main (#7044)
web: bump the eslint group in /web with 1 update (#7039)
web: bump the eslint group in /tests/wdio with 1 update (#7037)
web: bump @typescript-eslint/parser from 6.7.3 to 6.7.4 in /web (#7041)
core: bump ruff from 0.0.291 to 0.0.292 (#7040)
web: bump @typescript-eslint/parser from 6.7.3 to 6.7.4 in /tests/wdio (#7038)
web: bump @wdio/mocha-framework from 8.16.12 to 8.16.17 in /tests/wdio (#7032)
web: bump @wdio/cli from 8.16.12 to 8.16.18 in /tests/wdio (#7033)
web: bump @wdio/spec-reporter from 8.16.12 to 8.16.17 in /tests/wdio (#7034)
web: bump @wdio/local-runner from 8.16.12 to 8.16.18 in /tests/wdio (#7036)
web: bump the sentry group in /web with 2 updates (#7035)
* web/wdio-2:
remove hooks
add basic CI
prettier run
add dependabot
update package name
fix blueprints
web: improve testing by adding test admin user via blueprint
* web/add webdriverIO testing layer
This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both
locally and remotely, supports strong integration with web components, and is generally robust for
use in pipelines. I'll confess to working through a tutorial on how to do this for web components,
and this is just chapter 2 (I think there are 5 or so chapters...).
There's a makefile, with help! If you just run `make` it tells you:
```
Specify a command. The choices are:
help Show this help
node_modules Runs `npm install` to prepare this feature
precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write
test-good-login Test that we can log into the server. Requires a running instance of the server.
test-bad-login Test that bad usernames and passwords create appropriate error messages
```
... because Makefiles are documentation, and documentation belongs in Makefiles.
I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major
components (a page, a form, a wizard), there's a class that provides human-readable names for
human-interactable and human-viewable objects on the page. The LoginPage object, for example, has
selectors for the username, password, submit button, and the failure alert; accessing those allows
us to test for items as expected., and to write a DSL for "a good login" that's as straightforward
as:
```
await LoginPage.open();
await LoginPage.login("ken@goauthentik.io", "eat10bugs");
await expect(UserLibraryPage.pageHeader).toHaveText("My applications");
```
There was a *lot* of messing around with the LoginPage to get the username and password into the
system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because
we both keep the buttons inaccessible until the form has something and we "black out" the page (put
a darkening filter over it) while accessing the flow, meaning there was a race condition such that
the test would attempt to interact with the username or password field before it was accessible.
But this works now, which is very nice.
``` JavaScript
get inputUsername() {
return $('>>>input[name="uidField"]');
}
get btnSubmit() {
return $('>>>button[type="submit"]');
}
async username(username: string) {
await this.inputUsername.waitForClickable();
await this.inputUsername.setValue(username);
await this.btnSubmit.waitForEnabled();
await this.btnSubmit.click();
}
```
The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my
guardrails.
* web/adding tests: added comments and cleaned up some administrative features.
* web/test: changed the name of one test to reflect it's 'good' status
* web: improve testing by adding test admin user via blueprint
* fix blueprints
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* update package name
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add dependabot
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* prettier run
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add basic CI
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* remove hooks
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
This commit continues the application wizard buildout. In this commit are the following changes:
- Fixed a width-setting bug in the Makefile `make help` feature (i.e "automate that stuff!")
- Added Radius to the list of providers we can offer via the wizard
- Added `launchUrl` and `UI Settings` to features of the application page the wizard can find
- Changed 'SAML Manual Configuration' to just say "SAML Configuration"
- Modified `ak-form-group` to take and honor the `aria-label` property (which in turn makes it
easier to target specific forms with unit testing)
- Reduced the log level for wdio to 'warn'; 'info' was super-spammy and not helpful. It can be put
back with `--logLevel info` from the command line.
- Added SCIM to the list of available providers
- Fixed ForwardProxy so that its mode is set correctly. (This is a special case in the committer;
I'm unhappy with that.)
- Fixed the commit messages so that:
- icons are set correctly (Success, Danger, Working)
- icons are colored correctly according to state
- commit message includes a `data-commit-state` field so tests can find it!
- Merged the application wizard tests into a single test pass
- Isolated common parts of the application wizard tests to reduce unnecessary repetition. All
application tests are the same until you reach the provider section anyway.
- Fixed the unit tests so they're finding the right error messages and are enabled to display them
correctly.
- Moved the test Form handlers into their own folder so they're not cluttering up the Pages folder.
* web/wdio-2:
web/test: changed the name of one test to reflect it's 'good' status
web/adding tests: added comments and cleaned up some administrative features.
web/add webdriverIO testing layer
This commit adds WebdriverIO as an end-to-end solution to unit testing. WebdriverIO can be run both
locally and remotely, supports strong integration with web components, and is generally robust for
use in pipelines. I'll confess to working through a tutorial on how to do this for web components,
and this is just chapter 2 (I think there are 5 or so chapters...).
There's a makefile, with help! If you just run `make` it tells you:
```
Specify a command. The choices are:
help Show this help
node_modules Runs `npm install` to prepare this feature
precommit Run the precommit: spell check all comments, eslint with sonarJS, prettier-write
test-good-login Test that we can log into the server. Requires a running instance of the server.
test-bad-login Test that bad usernames and passwords create appropriate error messages
```
... because Makefiles are documentation, and documentation belongs in Makefiles.
I've chosen to go with a PageObject-oriented low-level DSL; what that means is that for each major
components (a page, a form, a wizard), there's a class that provides human-readable names for
human-interactable and human-viewable objects on the page. The LoginPage object, for example, has
selectors for the username, password, submit button, and the failure alert; accessing those allows
us to test for items as expected., and to write a DSL for "a good login" that's as straightforward
as:
```
await LoginPage.open();
await LoginPage.login("ken@goauthentik.io", "eat10bugs");
await expect(UserLibraryPage.pageHeader).toHaveText("My applications");
```
There was a *lot* of messing around with the LoginPage to get the username and password into the
system. For example, I had to do this with all the `waitForClickable` and `waitForEnable` because
we both keep the buttons inaccessible until the form has something and we "black out" the page (put
a darkening filter over it) while accessing the flow, meaning there was a race condition such that
the test would attempt to interact with the username or password field before it was accessible.
But this works now, which is very nice.
``` JavaScript
get inputUsername() {
return $('>>>input[name="uidField"]');
}
get btnSubmit() {
return $('>>>button[type="submit"]');
}
async username(username: string) {
await this.inputUsername.waitForClickable();
await this.inputUsername.setValue(username);
await this.btnSubmit.waitForEnabled();
await this.btnSubmit.click();
}
```
The bells & whistles of *Prettier*, *Eslint*, and *Codespell* have also been enabled. I do like my
guardrails.
This commit replaces the previous WDIO instance with a more formal and straightforward process using
the [pageobjects](https://martinfowler.com/bliki/PageObject.html). In this form, every major
component has its own test suite, and a test is a sequence of exercises of those components.
A test then becomes something as straightforward as:
```
await LoginPage.open();
await LoginPage.login("ken@goauthentik.io", "eat10bugs");
expect(await UserLibraryPage.pageHeader).toHaveText("My Applications");
await UserLibraryPage.goToAdmin();
expect(await AdminOverviewPage.pageHeader).toHaveText("Welcome, ");
await AdminOverviewPage.openApplicationsListPage();
expect(await ApplicationsListPage.pageHeader).toHaveText("Applications");
ApplicationsListPage.startCreateApplicationWizard();
await ApplicationWizard.app.name.setValue(`Test application ${newId}`);
await ApplicationWizard.nextButton.click();
await (await ApplicationWizard.getProviderType("ldapprovider")).click();
await ApplicationWizard.nextButton.click();
await ApplicationWizard.ldap.setBindFlow("default-authentication-flow");
await ApplicationWizard.nextButton.click();
await expect(await ApplicationWizard.commitMessage).toHaveText(
"Your application has been saved"
);
```
Whether or not there's another layer of DSL in there or not, this is a pretty nice idiom for
maintaining tests.
After working with the navigation for awhile, I realized that it's a poor map; what I really wanted was
a controller/view pair, where events flow up to the controller and then messages on "what to draw" flow
down to the view. It work quite well, and the wizard frame is smaller and smarter for it.
I've also moved the WDIO-driven tests into the 'tests' folder, because it (a) makes more sense to put
them there, and (b) it prevents any confusion about who's in charge of node_modules.
