* web: fix Flash of Unstructured Content while SearchSelect is loading from the backend
Provide an alternative, readonly, disabled, unindexed input object with the text "Loading...", to be
replaced with the _real_ input element after the content is loaded.
This provides the correct appearance and spacing so the content doesn't jiggle about between the
start of loading and the SearchSelect element being finalized. It was visually distracting and
unappealing.
* web: comment on state management in API layer, move file to point to correct component under test.
* web: test for flash of unstructured content
- Add a unit test to ensure the "Loading..." element is displayed correctly before data arrives
- Demo how to mock a `fetchObjects()` call in testing. Very cool.
- Make distinguishing rule sets for code, tests, and scripts in nightmare mode
- In SearchSelect, Move the `styles()` declaration to the top of the class for consistency.
- To test for the FLOUC issue in SearchSelect.
This is both an exercise in mocking @beryju's `fetchObjects()` protocol, and shows how we can unit
test generic components that render API objects.
* web: interim commit of the basic sortable & selectable table.
* web: added basic unit testing to API-free tables
Mostly these tests assert that the table renders and that the content we give it
is where we expect it to be after sorting. For select tables, it also asserts that
the overall value of the table is what we expect it to be when we click on a
single row, or on the "select all" button.
* web: finalize testing for tables
Includes documentation updates and better tests for select-table.
* Provide unit test accessibility to Firefox and Safari; wrap calls to manipulate test DOMs directly in a browser.exec call so they run in the proper context and be await()ed properly
* web: repeat is needed to make sure sub-elements move around correctly. Map does not do full tracking.
* web: Update HorizontalLightComponent to accurately convey its value "upwards."
* interim commit, gods, the CSS is finally working.
* web: update
Got the binding editor in. The tests complete. Removed sonarjs.
* web: fixed tests to complete.
* web: fixed round-trip between binding list and binding editor. Fixed 'delete'. TODO: Fix error reporting on home page, the edit button is ugly, and the height is off somehow, but I'm not yet sure how. I just know it bugs my eyes.
* core: add support to set policy bindings in transactional endpoint
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* improve permission checks
especially since we'll be using the wizard as default in the future, it shouldn't be superuser only
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: update api-less tables
- Replace `th` with `td` in `thead` components. Because Patternfly.
- Add @beryju's styling to the tables, which make it much better looking
* web: wizard for applications, now with bindings!
- Add policy bindings to the application wizard
- Restructures the Wizard base code.
- ak-wizard-steps holds the steps and listens for NavigationRequest events to move
from one step to the next.
- WizardStep is a base class (no component registration provided) that provides the *whole frame*,
not just the form. It receives the navigation content for the sidebar from ak-wizard-steps,
and provides the styling for the header, footer, sidebar, and main form. It has abstractions
for `buttons`, `renderMain()`, `handleButton()`, `handleEnable()`, in a section well-marked as
"Public API". Steps inherit from this class.
Conceptually:
- A wizard is a series of pages ("steps") with a distinct beginning and end, linked in a series,
to complete a task.
- Later steps in the series are inaccessible until an earlier steps has granted access to it.
- Access is predicated on the earlier step being complete and valid. The developer is responsible
for determining what "complete and valid" means.
- The series is visible, giving the customer a sense of how much effort is needed to complete the
task.
- A parent object maintains (and can modify as needed) the list of steps. It *can* maintain the
information being collected from the user. Alternatively, that information can be kept in each
step.
Details:
- Keeping with the Lit paradigm, "requests to change the system flow up, information changed by
valid requests flows down."
- The information flows up using events: WizardNavigation, WizardUpdate, WizardClose.
- The information flows down using properties.
- ak-application-wizard-main holds the list of steps, providing a unique slot name for each.
- It maintains the ApplicationWizardState object.
- ApplicationWizardStep inherits from WizardStep and provides:
- A means of extraction information from forms
- A convenience method for updating the ApplicationWizardState object, enabling future steps, and
navigating to a future step, in the correct order.
- A method for cleaning error from the error reporting mechanism as the user navigates from an
error-handling state.
- The title, description, and cancelability of the wizard.
- Steps:
- step: Handles the application. A good starting point for understanding the point of
the Wizard. Check the `handleButton()` method to understand how we enable or disable access to
future steps.
- provider-choice: Just a list. Shows validation without the form.
- provider: Uses a *very* esoteric Lit feature, `unsafeStaticTag`, which enables
the display to show anything that conforms to the expectations of ApplicationWizardProviderForm.
- ApplicationWizardProviderForm repeats some of the base of ApplicationWizardStep, but allows us
to provide multiple variants on a single form without having to create separate steps for each
form.
- The forms (`provider-for-ldap`, `provider-for-radius`) are therefore *just* the form and any
fetchers needed to populate it.
- bindings: Shows the table of bindings. Has a custom display for "This table is empty."
- edit-binding: Showcase for the `SearchSelectEZ` configuration format. Has an override on the
`handleButton` feature to figure out which binding is about to be overridden. Is also a
`.hidden` page; it doesn't show up on the navigation sidebar, as is only navigable-to by buttons
not associated with the button bar at the bottom.
- submit: Has a lot of machinery of state: Reviewing with errors, reviewing without errors,
running submission, and success. Uses `ts-pattern` a lot to make sure the state/request pairs
make sense.
The key insight is that, even though a wizard is a series in order, that order can't be simply
maintained in a list. The parent needs various strategies for swapping pages in and out of the
sequence, while still maintaining a coherent idea of "flow" and providing the visual cues the user
needs to feel confident that the work can be completed and completed quickly. The entire mechanism
for using an array and index to navigate, with index numbering, blocked the implementation of the
bindings pages.
One thing led to another. *Sigh* Really wish this hadn't been as much of a mess as it turned out.
The end result is pretty good, though. Definitely re-usable.
One important feature to note is that the wizard is *not* tied to the ModalButton object; it's
simply embedded in a modal as-needed. This allows us to use wizards in other places, such as just
being in a DIV, or just a page on its own.
* web: rollback dependabot "upgrade" that broke testing
Dependabot rolled us into WebdriverIO 9. While that's probably the
right thing to do, right now it breaks out end-to-end tests badly.
Dependabot's mucking with infrastructure should not be taken lightly,
especially in cases when the infrastructure is for DX, not UX, and
doesn't create a bigger attack surface on the running product.
* web: small fixes for wdio and lint
- Roll back another dependabot breaking change, this time to WebdriverIO
- Remove the redundant scripts wrapping ESLint for Precommit mode. Access to those modes is
available through the flags to the `./web/scripts/eslint.mjs` script.
- Remove SonarJS checks until SonarJS is ESLint 9 compatible.
- Minor nitpicking.
* web: not sure where all these getElement() additions come from; did I add them? Anyway, they were breaking the tests, they're a Wdio9-ism.
* package-lock.json update
* web: small fixes for wdio and lint
**PLEASE** Stop trying to upgrade WebdriverIO following Dependabot's instructions. The changes
between wdio8 and wdio9 are extensive enough to require a lot more manual intervention. The unit
tests fail in wdio 9, with the testbed driver Wdio uses to compile content to push to the browser
([vite](https://vitejs.dev) complaining:
```
2024-09-27T15:30:03.672Z WARN @wdio/browser-runner:vite: warning: Unrecognized default export in file /Users/ken/projects/dev/web/node_modules/@patternfly/patternfly/components/Dropdown/dropdown.css
Plugin: postcss-lit
File: /Users/ken/projects/dev/web/node_modules/@patternfly/patternfly/components/Dropdown/dropdown.css
[0-6] 2024-09-27T15:30:04.083Z INFO webdriver: BIDI COMMAND script.callFunction {"functionDeclaration":"<Function[976 bytes]>","awaitPromise":true,"arguments":[],"target":{"context":"8E608E6D13E355DFFC28112C236B73AF"}}
[0-6] Error: Test failed due to following error(s):
- ak-search-select.test.ts: The requested module '/src/common/styles/authentik.css' does not provide an export named 'default': SyntaxError: The requested module '/src/common/styles/authentik.css' does not provide an export named 'default'
```
So until we can figure out why the Vite installation isn't liking our CSS import scheme, we'll
have to soldier on with what we have. At least with Wdio 8, we get:
```
Spec Files: 7 passed, 7 total (100% completed) in 00:00:19
```
* Forgot to run prettier.
* web: small fixes for elements and forms
- provides a new utility, `_isSlug_`, used to verify a user input
- extends the ak-horizontal-component wrapper to have a stronger identity and available value
- updates the types that use the wrapper to be typed more strongly
- (Why) The above are used in the wizard to get and store values
- fixes a bug in SearchSelectEZ that broke the display if the user didn't supply a `groupBy` field.
- Adds `@wdio/types` to the package file so eslint is satisfied wdio builds correctly
- updates the end-to-end test to understand the revised button identities on the login page
- Running the end-to-end tests verifies that changes to the components listed above did not break
the semantics of those components.
* Prettier had opinions
* Fix the oauth2 provider test.
* web: fix oauth2 provider. Fix resolutions in package-lock.json
* Provide an error field for the form errors on the OAuth2 form. Unfortunately, this does not solve the general problem that we have a UX issue with which stage bindings to show where now that we've introduced the Invalidation Stage.
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* web/admin: provide default invalidation flows for LDAP provider.
* admin/web: the default invalidation flows for LDAP and Radius are different from the others.
* Updating the SAML Wizard page to correspond to the provider page. *This is an intermediate fix to get the tests passing. It will probably be mooted with the next revision.*
* Making progress...
* web/admin: provider formectomy complete
* fix minor issues
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* custom ordering for provider types
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix css
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix missing PFBase causing wrong font
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix missing card for type select
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix padding on last page
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add card to bindings
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web/element/wizard: fix the CSS cascade so the modifications to the title display don't affect the wiard header.
* web/elements/wizard: fix logic on unavailable / available / current indicators in nav bar.
* Debugging code is not needed.
* web: small visual fixes
As requested by reviewers:
- Fixed the height to 75% of the viewport
- Put 1rem of whitespace between the hint label and the Wizard startup button.
* web: disable lint check for cAsEfUnNy AtTrIbUtE nAmEs.
* Apply suggestions from code review
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Signed-off-by: Jens L. <jens@beryju.org>
* rework title
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* format
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Jens L. <jens@beryju.org>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Translate locale/en/LC_MESSAGES/django.po in it
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'it'.
Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
* Translate locale/en/LC_MESSAGES/django.po in es
100% translated source file: 'locale/en/LC_MESSAGES/django.po'
on 'es'.
---------
Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
Update Home Assistant integration docs
Extra care should be taken to proxy only /auth endpoint through Authentik.
Signed-off-by: Sergii Bogomolov <sergii@bogomolov.io>
Co-authored-by: Tana M Berry <tanamarieberry@yahoo.com>
* flows: add FlowPlan .to_redirect helper to redirect to flow executor
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* flows: add initial silent flow executor
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* more cleanup
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* refactor and add tests
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* how'd that happen
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix most tests
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* don't set allowed_silent_types if we cant transmit data via URL
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix stage not being set early enough
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix OAuthDeviceCodeFinishStage being marked able-to-be-skipped-to when it is not
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* fix more tests
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* dont skip on rac for now
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add support for SAML redirect
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Docker Compose Updates Healthcheck
The Healthcheck is not used for the depends_on option. This change ensures all dependencies are all ready to work before starting worker and server container.
Signed-off-by: Kaindl Network <82705244+kaindlnetwork@users.noreply.github.com>
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* web: streamline CaptchaStage
# What
This commit:
1. Replaces the mass of `if () { if() { if() } }` with two state tables:
- One for `render()`
- One for `renderBody()`
2. Breaks each Captcha out into "interactive" and "executive" versions
3. Creates a handler table for each Captcha type
4. Replaces the `.forEach` expression with a `for` loop.
5. Move `updated` to the end of the class.
6. Make captchDocument and captchaFrame constructed-on-demand with a cache.
7. Remove a lot of `@state` handlers
8. Give IframeMessageEvent its own type.
9. Removed `this.scriptElement`
10. Replaced `window.removeEventListener` with an `AbortController()`
# Why
1. **Replacing `if` trees with a state table.** The logic of the original was really hard to follow.
With the state table, we can clearly see now that for the `render()` function, we care about the
Boolean flags `[embedded, challenged, interactive]` and have appropriate effects for each. With
`renderBody()`, we can see that we care about the Boolean flags `[hasError, challenged]`, and can
see the appropriate effects for each one.
2. (and 3.) **Breaking each Captcha clause into separate handlers.** Again, the logic was convoluted,
when what we really care about is "Does this captcha have a corresponding handler attached to
`window`, and, if so, should we run the interactive or executive version of it?" By putting all
of that into a table of `[name, challenge, execute]`, we can clearly see what's being handled
when.
4. **Replacing `foreach()` with `for()`**: [You cannot use a `forEach()` with async
expressions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach#:~:text=does%20not%20wait%20for%20promises).
If you need asynchronous behavior in an ordered loop, `for()` is the safest way to handle it; if
you need asynchronous behavior from multiple promises, `Promise.allSettled(handlers.map())` is
the way to go.
I tried to tell if this function *meant* to run every handler it found simultaneously, or if it
meant to test them in order; I went with the second option, breaking and exiting the loop once a
handler had run successfully.
5. **Reordered the code a bit**. We're trying to evolve a pattern in our source code: styles,
properties, states, internal variables, constructor, getters & setters that are not `@property()`
or `@state()`, DOM-related lifecycle handlers, event handlers, pre-render lifecycle handlers,
renderers, and post-render lifecycle handlers. Helper methods (including subrenderers) go above
the method(s) they help.
6. **Constructing Elements on demand with a cache**. It is not guaranteed that we will actually need
either of those. Constructing them on demand with a cache is both performant and cleaner.
Likewise, I removed these from the Lit object's `state()` table, since they're constructed once
and never change over the lifetime of an instance of `ak-stage-captcha`.
9. **Remove `this.scriptElement`**: It was never referenced outside the one function where it was used.
10. **Remove `removeEventListener()`**: `AbortController()` is a bit more verbose for small event
handler collections, but it's considered much more reliable and much cleaner.
* Didn't save the extracted ListenerController.
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* web: simplify `?inline` handler for Storybook
# What
- Revise the `?inline` handler for Storybook
- Enable headless test runs of E2E
- Reduce headless testing to single instances
# Why
## `?inline` handling
Vite-for-Storybook-for-Web-Components has a requirement that all component CSS imports be
suffixed with an `?inline` argument so Vite knows to put the CSS into the component and
not inject it into the document head.
This `?inline` argument is an implementation detail of Storybook. It would be irrelevant clutter
added to our codebase. We were using `rollup-plugin-modify` to find every instance of an
import-to-component, but the implementation was clunky and involved scanning the source code
manually.
`rollup-plugin-modify` version 3 has regular expressions and takes a function as an argument. This
allows us to generate the CSS import maps on-the-fly when Storybook is run, eliminating a fragile
build step. We can also remove the source code scanner for those imports.
## Changes to testing
It's just nice to be able to run the E2E tests headlessly, without them eating up your screen real
estate, flashing, or grabbing your mouse.
WebdriverIO's testing of Web Components is new and, as we've seen, a bit cranky. The WebdriverIO
team currently recommends not running the tests in parallel. We only have about 70 tests so far, and
they're fairly speedy, especially when you don't have to invoke a browser session for every test.
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* Start of dual select revision process.
* Progress.
* Made the RuleFormHelper's dualselect conform.
* Providers and Selectors harmonized for sources.
* web/bugfix/dual-select-full-options
# What
- Replaces the dual-select "selected" list mechanism with a more comprehensive (if computationally
expensive) version that is correct.
# How
In the previous iteration, each dual select controller gets a *provider* and a *selector*; the
latter keeps the keys of all the objects a specific instance may have, and marks those objects as
"selected" when they appear in the dual-selects "selected" panel.
In order to distinguish between "selected on the existing instance" and "selected by the user," the
*selector* only runs at construction time, creating a unified "selected" list; this is standard and
allows for a uniform experience of adding and deleting items. Unfortunately, this means that the
"selected" items, because their displays are crafted bespoke, are only chosen from those available
at construction. If there are selected items later in the paginated collection, they will not be
marked as selected.
This defeats the purpose of having a paginated multi-select!
The correct way to do this is to retrieve every item pased to the *selector* and use the same
algorithm to craft the views in both windows.
For every instance of Dual Select with dynamic selection, the *provider* and *selector* have been
put in a separate file (usually suffixed as a `*FormHelper.ts` file); the algorithm by which an item is
crafted for use by DualSelect has been broken out into a small function (usually named
`*toSelect()`). The *provider* works as before. The *selector* takes every instance key passed to it
and runs a `Promise.allSettled(...*Retrieve({ uuid: instanceId }))` on them, mapping them onto the
`selected` collection using the same `*toSelect()`, so they resemble the possibilities in every way.
# Lessons
This exercise emphasizes just how much sheer *repetition* the Django REST API creates on the client
side. Every Helper file is a copy-pasta of a sibling, with only a few minor changes:
- How the objects are turned into displays for DualSelect
- The type and calls being used;
- The field on which retrival is defined
- The defaulting rule.
There are 19 `*FormHelper` files, and each one is 50 lines long. That's 950 lines of code.
Of those 950 lines of code, 874 of those lines are *complete duplicates* of those in the other
FormHelper files. Only 76 lines are unique.
This language really needs macros. That, or I need to seriously level up my Typescript and figure
out how to make this whole thing a lot smarter.
* order fields by field_key and order
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: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* web: fix selector warnings in WebdriverIO
Despite the [promises made](https://webdriver.io/docs/selectors#deep-selectors) by the WebdriverIO
team, we are still getting a lot of warnings and "falling back to pre-BIDI behavior" messages
when we attempt to access ShadowDOM contexts without the "pierce" (`>>>`) syntax. So I've put
it back wherever it occurred and the system now uses the BIDI controllers correctly.
* web: update to Chromedriver 131 breaks a lot of stuff
This annoying bit of janitorial work cleans up the failure messages and resolution bugs
that arose when updating to the latest version of Chrome. Keeping track of all the
weakness and breakage while the in-browser testing teams figure out how to live with
the ShadowDOM is just really time-consuming.
This change adds an admonition to document the fact that every role can only ever be assigned to a single group at the same time. Since this is surprising based on a traditional understanding of role-based models, I've decided to make this a `:::warning`.
I'm undecided on the best place for this information, but for now, decided on putting it into the context of the action that can fail: assigning a role to a group.
While this does not close the issue, it documents this behavior to at least address the "needs documentation" aspect of #10983 .
Signed-off-by: Zuri Klaschka <pklaschka@users.noreply.github.com>
While for role memberships, it is true that they are only applied for _direct_ memberships, this does not appear to be the case for attributes (which is good as this also follows the "Hierarchy" system documented in the same file).
In terms of the implementation, this is the case due to the call to `all_groups()` in 3d5a189fa7/authentik/core/models.py (L312-L313), introduced in https://github.com/goauthentik/authentik/pull/6017. Looking through the files in there, it is clear that this line in the documentation is from before that point: 95e60a035d/website/docs/user-group/group.md (L15).
tl;dr: the documentation was correct before #6017, but is now out of date. This change fixes that.
Signed-off-by: Zuri Klaschka <pklaschka@users.noreply.github.com>
* web: Add InvalidationFlow to Radius Provider dialogues
## What
- Bugfix: adds the InvalidationFlow to the Radius Provider dialogues
- Repairs: `{"invalidation_flow":["This field is required."]}` message, which was *not* propagated
to the Notification.
- Nitpick: Pretties `?foo=${true}` expressions: `s/\?([^=]+)=\$\{true\}/\1/`
## Note
Yes, I know I'm going to have to do more magic when we harmonize the forms, and no, I didn't add the
Property Mappings to the wizard, and yes, I know I'm going to have pain with the *new* version of
the wizard. But this is a serious bug; you can't make Radius servers with *either* of the current
dialogues at the moment.
* docs: fix link from project root to the Contributing documentation in our product.
* don't push when on internal repo
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* only run certain workflows on main repo
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* add mirror
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* how tf did a tab get in there
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* ooops
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
@ -2,7 +2,7 @@ authentik takes security very seriously. We follow the rules of[responsible di
## Independent audits and pentests
In May/June of 2023 [Cure53](https://cure53.de) conducted an audit and pentest. The [results](https://cure53.de/pentest-report_authentik.pdf) are published on the [Cure53 website](https://cure53.de/#publications-2023). For more details about authentik's response to the findings of the audit refer to [2023-06 Cure53 Code audit](https://goauthentik.io/docs/security/2023-06-cure53).
We are committed to engaging in regular pentesting and security audits of authentik. Defining and adhering to a cadence of external testing ensures a stronger probability that our code base, our features, and our architecture is as secure and non-exploitable as possible. For more details about specfic audits and pentests, refer to "Audits and Certificates" in our [Security documentation](https://docs.goauthentik.io/docs/security).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
