[BUG] Cannot use Elsa: `Scheme already exists: Bearer` about elsa-core HOT 5 OPEN

That may not be a bad idea. Originally, the default configuration is just there to get started quickly, but usually you'll want to handle authentication yourself, in which case you may not want to use the default setup other than perhaps as an example. However, that also means you'd need to handle setting up the claims identity such that it has the permissions claim. If we just offer a default setup using a different scheme, then perhaps it can work side by side with an application specific scheme (which probably is called Bearer as you mentioned)

from elsa-core.

The exception you're encountering indicates that there is an attempt to add an authentication scheme with the name "Bearer" more than once. This can happen if AddAuthentication is called multiple times with the same scheme or if different parts of the code are trying to configure the same authentication scheme independently.

To resolve this issue, you should ensure that the "Bearer" scheme is only added once throughout your application's startup configuration. Here are some steps you can take:

1. Search your codebase for all occurrences of AddAuthentication and AddJwtBearer to see if the "Bearer" scheme is being added more than once.
2. If you are using external libraries or packages that add authentication schemes, make sure they are not conflicting with your own authentication configuration.
3. Check the order of operations in your startup configuration. Sometimes the order in which services are added can cause issues.
4. If you have multiple projects or modules that are being integrated, ensure that they are not each trying to add the same authentication scheme.

Without seeing the actual code, it's difficult to provide a precise solution. However, the general approach is to review and consolidate your authentication configuration to prevent duplicate scheme registrations.

If you continue to have trouble, please provide more details about your startup configuration, especially around the authentication and authorization setup, so that a more specific solution can be provided.

This comment was generated by Glime.

from elsa-core.

From what I'm reading, perhaps elsa should chose a more specific name for it's authentication schema? 🤔

Most applications are, by default, going to be using JwtBearerDefaults.AuthenticationScheme since that's what is automatically configured for them if they have setup JWT auth. Which means the canonical JWT auth setup is in conflict with elsa.

This call can specify the schema name:

from elsa-core.

That's a good point actually 🤔 , I have not yet integrated my auth scheme into Elsa. Actually, I have no idea how even!

I agree that most will move away from the default, but to ease the onboarding pain the default may want to be named something different to avoid the conflcit!

from elsa-core.

If elsa is not explicitly specifying the Authorization scheme to use, then I don't think it will work at all if an existing default one exists. Regardless of it one was to integrate their own identity or not no?

The IdentityFeature also appears tosupply defaults for some of these services, how can this be changed?

            .AddScoped<ISecretHasher, DefaultSecretHasher>()
            .AddScoped<IAccessTokenIssuer, DefaultAccessTokenIssuer>()
            .AddScoped<IUserCredentialsValidator, DefaultUserCredentialsValidator>()
            .AddScoped<IApplicationCredentialsValidator, DefaultApplicationCredentialsValidator>()
            .AddScoped<IApiKeyGenerator>(sp => sp.GetRequiredService<DefaultApiKeyGeneratorAndParser>())
            .AddScoped<IApiKeyParser>(sp => sp.GetRequiredService<DefaultApiKeyGeneratorAndParser>())
            .AddScoped<IClientIdGenerator, DefaultClientIdGenerator>()
            .AddScoped<ISecretGenerator, DefaultSecretGenerator>()
            .AddScoped<IRandomStringGenerator, DefaultRandomStringGenerator>()
            .AddScoped<DefaultApiKeyGeneratorAndParser>()

from elsa-core.