Activities of "enisn"

Hi,

It's hard to determine the exact problem right now but here is some extra suggestions to find the source of problem and we can help then:

1. Investigate Dependencies: The error indicates a problem with Microsoft.Extensions.DependencyInjection.ActivatorUtilities.CreateInstance. Ensure that all dependencies related to this library are properly included in your project and container. Sometimes, certain assemblies may not be copied during the publishing process. Verify the contents of the bin/Release/net9.0/publish/ folder.

2. Check .NET Version: Ensure the container is using the correct version of the .NET runtime that matches your application's target framework. The Dockerfile uses mcr.microsoft.com/dotnet/aspnet:9.0, so confirm this aligns with your application.

3. Debug Assembly Loading: Since this issue occurs only in the containerized environment, it could be related to assembly loading. You might need to explicitly include certain assemblies in the Dockerfile or publishing settings.

4. Test with Minimal Setup: Try running the application in a simpler containerized environment, like Docker alone, instead of Kubernetes. This can help isolate Kubernetes-specific issues.

5. Update ABP Framework: If you're not using the latest version of ABP Framework, consider updating it to rule out potential framework bugs.

6. WebAssembly Module Loading: The error happens when loading the WebAssembly UI module. Look into how the module is loaded and initialized, especially in a containerized environment. Ensure any required configuration files for the WebAssembly module are accessible within the container.

7. Logs and Diagnostics: Examine the application and container logs closely. While you mentioned the pod logs are clear, additional diagnostic tools like dotnet-dump or dotnet-trace could provide insights into what happens at the point of failure.

These steps aim to help pinpoint the source of the issue and resolve the containerized deployment problem. Further information may help us to undertsand and solve the problem

Hi,

Since it's a still a Blazor application, you can implement your own AuthenticationStateProvider and notify authentication system from single point like something similar:

[Volo.Abp.DependencyInjection.Dependency(ReplaceServices = true)]
[ExposeServices(typeof(AuthenticationStateProvider))]
public class CustomAuthenticationStateProvider : AuthenticationStateProvider, ISingletonDependency
{
    private ClaimsPrincipal _currentUser = new ClaimsPrincipal(new ClaimsIdentity());
    
    public void NotifyUserChanged(ClaimsPrincipal user)
    {
        _currentUser = user;
        NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
    }

    public override Task<AuthenticationState> GetAuthenticationStateAsync()
    {
        return Task.FromResult(new AuthenticationState(_currentUser));
    }
}

You can call NotifyUserChanged by injecting singleton CustomAuthenticationStateProvider service to notify all the existing components about the state is changed.

We also faced a similar problem during the investigation, we'll try to find a solution on framework level, but for now this can be a workaround

The error message indicates that the requested authorization policy was not granted, stemming from either a configuration issue or missing permissions. Based on the details provided, here are a few steps to troubleshoot the issue:

1. Policy Configuration:

   • Verify that the required authorization policy is correctly defined in your project. Policies in ABP Framework can be set in the Startup.cs file using the ConfigureServices method. Ensure that the specific policy mentioned is correctly implemented and mapped to roles or claims.

2. Azure App Registration Settings:

   • Double-check the settings for your Azure App Registration. Specifically:
     • Check API permissions to ensure the necessary scope is granted.
     • Validate Redirect URIs to match the URLs used in your application.
     • Ensure that Multi-Factor Authentication (MFA) settings align with the organization’s configuration. The error AADSTS50076 is often related to MFA requirements or configuration changes.

3. Claims Mapping:

   • Confirm that claims are being correctly mapped during authentication and that the claim used in the authorization policy is present. Check logs to ensure claims are being read correctly after login.

4. Logging and Debugging:

   • Enable detailed logging for your application to capture errors related to OpenIdConnect authentication.
   • Use tools like Fiddler or browser developer tools to analyze the authentication flow and see where issues might arise.

5. Check ABP Framework Configuration:

   • Verify the configuration settings for OpenIdConnect in your application, especially the identity server integration within ABP. Ensure your settings in appsettings.json align with Azure portal configuration.

Hi,

It seems you use Distributed event handler and and handler works completely separated context/thread than the original one that handles HTTP requests. So, TraceId cannot be acquired in that case.

You may want to transfer it manually while publishing the event

public class MyCustomEventData
{
    public string TraceId { get; set; }
    // ...
}

await distributedEventBus.PublishAsync(new MyCustomEventData 
{
    TraceId = httpContextAccessor.HttpContext.TraceIdentifier,
    // Set other properties as needed
});

Why Does This Happen?

When you handle an HTTP request, the current context (including any enrichers that incorporate data like the trace ID) is maintained on the thread handling that request. By the time your event handler executes, it’s on a different thread (or even a different process) where the ambient context isn’t preserved. This is why you observe that the trace ID, despite being available during the request, isn’t automatically available when the event handler starts processing the event.

Hi,

It depends on your scenario, if your domain strictly coupled to that external service, you can even make HTTP request in a DomainService. But most of cases, it's an application logic and calling your external API in the Application layer much more accurate but still it depends on the logic.

As a best practise, I can suggest you to create a contracts or client package built as a new library and implement all the sending logic in that class library and consume it from your ABP aplication. You can easily generate HTTP Client methods by using NSwag or equivalent tools if the API provides Open API information by swager etc.

Hi,

Can you check if the permission is given to your user or the role that your user has? To do that, nativagete to Identity Management > Roles| Users > Actions dropdown > Permissions

Hi,

Whenever the file name is exactly same, the service-worker and browser do not download it again. In this scenario, people uses v parameter in the querystring with the file hash or actual version like main.js?v=1f129b3...daab834 or main.js?v=1.0.2 etc.

Whenever the file path is changed even with querystring, it's considered as a new file and re-downloaded.

ABP startup templates already has this unique file hash as a version in the templates:

When you execute abp bundle command to update bundles, it'll update the hashes in the file links too.

If you face a problem with *.dll files, here you can follow this workaround.

1. Add id="global-script" to your <script> tag in App.razor file.

<script id="global-script" src="global.js?_v=638524142774706627"></script>

2. Go to service-worker.published.js file and create a function to store this version and check it:

function isVersionMismatch() {
    const globalScript = document.getElementById('global-script');
    const version = globalScript.getAttribute('src').split('?')[1];
    const cacheVersion = localStorage.getItem('abp.assets.version');

    // Update the cache version
    localStorage.setItem('abp.assets.version', version);
    return version !== cacheVersion;
}

3. Find onFetch function in the same file and append the check right at the begginning of the function to check version mismatch:

async function onFetch(event) {
    if (isVersionMismatch()) {
        return fetch(event.request);
    }

    // ... rest of the codes
}

You can use any IdentityModel Client package to use an OpenId Connect Authentication Server.

ABP already provides a package for it named Volo.Abp.Http.Client.IdentityModel https://abp.io/package-detail/Volo.Abp.Http.Client.IdentityModel

It has dependency to https://github.com/DuendeArchive/IdentityModel package. So you can follow it's instructions to configure it for more complex scenarios.

When whenever you use ABP's package and add it do [DependsOn] attribute, you can configure easily defining your credentials in appsettings something like this:

  "AuthServer": {
    "Authority": "https://localhost:44319",
    "RequireHttpsMetadata": true,
    "ClientId": "AbpSolution51_Web",
    "ClientSecret": "1q2w3e*"
  },

And make it configure in the *Module.cs file of your application:

context.Services.AddAuthentication(options =>
{
    options.DefaultScheme = "Cookies";
    options.DefaultChallengeScheme = "oidc";
})
.AddCookie("Cookies", options =>
{
    options.ExpireTimeSpan = TimeSpan.FromDays(365);
    options.CheckTokenExpiration();
})
.AddAbpOpenIdConnect("oidc", options =>
{
    options.Authority = configuration["AuthServer:Authority"];
    options.RequireHttpsMetadata = configuration.GetValue<bool>("AuthServer:RequireHttpsMetadata");
    options.ResponseType = OpenIdConnectResponseType.CodeIdToken;

    options.ClientId = configuration["AuthServer:ClientId"];
    options.ClientSecret = configuration["AuthServer:ClientSecret"];

    options.UsePkce = true;
    options.SaveTokens = true;
    options.GetClaimsFromUserInfoEndpoint = true;

    options.Scope.Add("roles");
    options.Scope.Add("email");
    options.Scope.Add("phone");
    options.Scope.Add("AbpSolution51");
});

Also you can create a new tiered application to see how it is configured properly.

It seems it's stuck while trying to initialize AbpHttpClientIdentityModelModule but there no special configuration in it. And it initialize AbpIdentityModelModule du to dependency to it. Nothing seems suspicious in that file.

It tries to get configuration by calling context.Services.GetConfiguration() method but I do not think it may be the problem. https://github.com/abpframework/abp/blob/rel-9.0/framework/src/Volo.Abp.IdentityModel/Volo/Abp/IdentityModel/AbpIdentityModelModule.cs

Can you try removing [DependsOn(typeof(AbpHttpClientIdentityModelModule))] attribute and try again to make sure if the problem is related to module initialization or not. And then we can start to investigation on module initialization if it's related to that

It seems it stucks while trying acuiring lock for IdentitySessionCleanupBackgroundWorker. The log says it already acquired the lock but this process takes a lot of time or it cannot perform the action: https://github.com/abpframework/abp/blob/d5087c6b940320a3e932be348812d32fe06255a8/modules/identityserver/src/Volo.Abp.IdentityServer.Domain/Volo/Abp/IdentityServer/Tokens/TokenCleanupBackgroundWorker.cs#L38-L41

Since it has "Start cleanup." logs at the beginning of the method: https://github.com/abpframework/abp/blob/d5087c6b940320a3e932be348812d32fe06255a8/modules/openiddict/src/Volo.Abp.OpenIddict.Domain/Volo/Abp/OpenIddict/Tokens/TokenCleanupService.cs#L36

Probably one of its dependencies cannot be resolved or causes a problem.

Can you try disabling background workers and deploy it again to make sure if it's the reason or not? https://abp.io/docs/latest/framework/infrastructure/background-workers#options

And also, you can set LogLevel as Debug to see more details about what happens before freezing