No warning when multiple providers with identical routing identifier used in same outpost

[Wykks]

Current Behavior

In a Module Federation context:

I have an React library with some code in the main entrypoint. I want to import a context, which is located in a secondary entrypoint.

I use additionalShared from ModuleFederationConfig to explicitly all entry point of my lib.

By the way this config additionalShared is really missing some documentation, it took us a while to find a way the share secondary entry points, as it's supposed to share automatically https://nx.dev/concepts/module-federation/manage-library-versions-with-module-federation#how-are-library-versions-determined , but it doesn't work out of the box. And this documentation doesn't mention that additionalShared exist.

Now back to the main issue: since @nx/enforce-module-boundaries "force" me to do a relative import, the relative import doesn't match in the additionalShared configuration, and thus break the share (and everything breaks, because the context is not a singleton anymore).

Expected Behavior

I've seen that the code of @nx/enforce-module-boundaries check for secondary entry points only for Angular https://github.com/nrwl/nx/blob/master/packages/eslint-plugin/src/rules/enforce-module-boundaries.ts#L385 (because in Angular we can't do relative import to secondary entry points to build the lib). But it should also do it for others framework/lib because of this.

GitHub Repo

No response

Steps to Reproduce

1. Create a simple module federation projet following https://nx.dev/concepts/module-federation/micro-frontend-architecture
2. Add a library with two entry points "@acme/myLib" "@acme/myLib/context"
3. Add a relative import from the first entry point to the second entry point
4. Configure additionalShared in module-federation config, for all apps like this:

  additionalShared: [{
    "@acme/myLib",
    sharedConfig: {
      requiredVersion: '0.0.1',
      eager: false,
    }, {
    "@acme/myLib/context",
    sharedConfig: {
      requiredVersion: '0.0.1',
      eager: false,
    }]
  })),

6. Import the library from the both micro-frontend apps
7. And some console log to check if the entry points are exactly loaded once

Nx Report

Node   : 20.14.0
OS     : linux-x64
npm    : 10.7.0

nx                 : 19.2.3
@nx/js             : 19.2.3
@nx/jest           : 19.2.3
@nx/linter         : 19.2.3
@nx/eslint         : 19.2.3
@nx/workspace      : 19.2.3
@nx/cypress        : 19.2.3
@nx/devkit         : 19.2.3
@nx/esbuild        : 19.2.3
@nx/eslint-plugin  : 19.2.3
@nx/react          : 19.2.3
@nrwl/tao          : 19.2.3
@nx/vite           : 19.2.3
@nx/web            : 19.2.3
@nx/webpack        : 19.2.3
typescript         : 5.4.5
---------------------------------------
Registered Plugins:
@nx/vite/plugin
@nx/eslint/plugin

Failure Logs

No response

Package Manager Version

No response

Operating System

• [ ] macOS
• [X] Linux
• [ ] Windows
• [ ] Other (Please specify)

Additional Information

No response

[BeryJu]

The definitely sounds like a bug, after successfully binding the outpost uses the /core/applications/{slug}/check_access/ API with the session that was just authenticated by the flow and thus it should correctly check access to the correct application. Although one thing that could also cause this behaviour is if both of your LDAP providers have the same base DN, as the outpost will use them to determine which application the request belongs to.

[Ma27]

Although one thing that could also cause this behaviour is if both of your LDAP providers have the same base DN, as the outpost will use them to determine which application the request belongs to.

Sorry, should've mentioned that, they do indeed (all the stuff used the same OpenLDAP server before, so I decided to keep the base DN to make it a little easier).

[BeryJu]

Having multiple LDAP providers with the same Base DN is supported, however they can't be in the same outpost

[Ma27]

So I hope I didn't just miss it in the docs somewhere, but I think it might help to display a warning if that is about to be configured, no?

[BeryJu]

There is a note towards the top of https://docs.goauthentik.io/docs/providers/ldap/, but it should definitely also be shown in the admin UI

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Ma27]

I think displaying a warning should be done here since it's very painful to debug if you made the mistake.

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Ma27]

https://fvsch.com/stale-bots