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.
id="global-script" to your <script> tag in App.razor file.<script id="global-script" src="global.js?_v=638524142774706627"></script>
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;
}
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
Hi
How can we specify which service tenant database a microservice should work with (e.g., Microservice_Tenant1_Products, Microservice_Tenant2_Products, etc.)?
Do you use micro-serivce template currently or you'll separate your services later? By default we don't suggest using different databases for tenants in the micro-service template currently, if you wish you can rea the discussion from here: https://abp.io/support/questions/8692/Problems-configuring-a-separate-database-for-each-tenant-in-a-microservices-application
If your template is not micro-service, you can customize MultiTenantConnectionStringResolver in your application
https://github.com/abpframework/abp/blob/74d516829be7f05cfae7d4a67f18591b41e5446a/framework/src/Volo.Abp.MultiTenancy/Volo/Abp/MultiTenancy/MultiTenantConnectionStringResolver.cs#L76-L79
using System;
using Microsoft.Extensions.Options;
using Volo.Abp.Data;
using Volo.Abp.DependencyInjection;
using Volo.Abp.MultiTenancy;
namespace AbpSolution1.AuthServer;
[Dependency(ReplaceServices = true)]
[ExposeServices(typeof(IConnectionStringResolver), typeof(DefaultConnectionStringResolver))]
public class MicroServiceConnectionStringResolver : MultiTenantConnectionStringResolver
{
private readonly ICurrentTenant _currentTenant;
private readonly IServiceProvider _serviceProvider;
public MicroServiceConnectionStringResolver(IOptionsMonitor<AbpDbConnectionOptions> options, ICurrentTenant currentTenant, IServiceProvider serviceProvider) : base(options, currentTenant, serviceProvider)
{
_currentTenant = currentTenant;
_serviceProvider = serviceProvider;
}
public override async Task<string> ResolveAsync(string? connectionStringName = null)
{
// ⚠️ Implement Your own logic, this is for demonstration
var prefix = "Microservice";
var postfix="Products";
var tenant = _currentTenant.Name;
// ...
return $"Server=myServerAddress;Database={prefix}_{tenant}_{postfix};Trusted_Connection=True;"
}
}
When we add new database migrations at the service, how should we handle them considering that each tenant has its own separate service database? how this migration will be applied to all service tenant dbs?
DbMigrator project applies migrations for all the tenants
Where should I put** "Resolving Entity Tracking Issue"** code from your above suggestion ?
Sorry, IdentityUser has AddLoginAsync not UpdateLoginAsync method. You can create your own IdentityUserManager and handle the external login in there. That can be a good point to start tracking what is going on
[Dependency(ReplaceServices = true)]
[ExposeServices(typeof(IdentityUserManager))]
public class MyIdentityManager : IdentityUserManager
{
public MyIdentityManager(
IdentityUserStore store,
IIdentityRoleRepository roleRepository,
IIdentityUserRepository userRepository,
IOptions<IdentityOptions> optionsAccessor,
IPasswordHasher<Volo.Abp.Identity.IdentityUser> passwordHasher,
IEnumerable<IUserValidator<Volo.Abp.Identity.IdentityUser>> userValidators,
IEnumerable<IPasswordValidator<Volo.Abp.Identity.IdentityUser>> passwordValidators,
ILookupNormalizer keyNormalizer,
IdentityErrorDescriber errors,
IServiceProvider services,
ILogger<IdentityUserManager> logger,
ICancellationTokenProvider cancellationTokenProvider,
IOrganizationUnitRepository organizationUnitRepository,
ISettingProvider settingProvider,
IDistributedEventBus distributedEventBus,
IIdentityLinkUserRepository identityLinkUserRepository,
IDistributedCache<AbpDynamicClaimCacheItem> dynamicClaimCache) : base(store, roleRepository, userRepository, optionsAccessor, passwordHasher, userValidators, passwordValidators, keyNormalizer, errors, services, logger, cancellationTokenProvider, organizationUnitRepository, settingProvider, distributedEventBus, identityLinkUserRepository, dynamicClaimCache)
{
}
public override async Task<IdentityResult> AddLoginAsync(Volo.Abp.Identity.IdentityUser user, UserLoginInfo login)
{
if(login.ProviderKey == "PingOne")
{
// Handle PingOne login
}
return await base.AddLoginAsync(user, login);
}
}```
Hi,
While you developing a Module, you shouldn't create migrations inside module since it's re-usable project that can be consumed by multiple applications. You should create migrations in your end application that consumes your module.
You can call builder.ConfigureModule1(); extension method in your application's DbContext to configure entities from your module and then create migrations in application. If you created DDD Module while creating it, there should already be Module1DbContextModelCreatingExtensions.cs and you can configure your entities there, you can configure entities from module in that extension method nad use it wherever you use use that module like any other ABP modules.
Hi,
Do you deploy database in the cluster at the same time, too? Since there is no error log it's pretty hard to understand the problem but there can be some connection problems such as trying to connect redis or database or other services if it's a microservice application
Hi,
It's possible but also it seems not stable.
ABP supports using database separation across tenants. Whenever you separate database for a tenant you'll not be able to combine all the data between tennats
In the scenario you'll use always same database;
You don't have to implement your own repositories. You can use CurrentTenant.Change() method inside a using scope to change the tenant you want to access its data.
using (CurrentTenant.Change(tenantId))
{
return await _productRepository.GetCountAsync();
}
Check here: https://abp.io/docs/latest/framework/architecture/multi-tenancy#change-the-current-tenant
You can iterate all the tenants inside a foreach loop in this way:
var tenants = await _tenantRepository.GetListAsync(includeDetails: true);
foreach (var tenant in tenants)
{
using (_currentTenant.Change(tenant.Id))
{
var users = _userRepository.GetList(/*...*/);
Logger.LogInformation($"Tenant {tenant.Name} has {users.Count} users.");
}
}
Hi,
It seems it's not an expected situation. I'll deliver this problem to the ABP Suite team and inform you about if it's bug or not.
Thanks