Activities of "gterdem"

If you are using containerized deployment, you should override the App__HealthCheckUrl to service name like:

App__HealthCheckUrl=http://api-service-name/health-status

Hello,

I understand that your requirement is not to change the appsettings but for troubleshooting the problem better, can you update the appsettings.json file App:SelfUrl and App:AngularUrl and deploy it to see if the problem lies with overriding the environment or if there is an internal bug related to the login confirmation mail link.

The integration services are non authorized endpoints and they should not be exposed to gateways.

There are two ways when using synchronous communication between microservices;

• If you want to consume an exposed endpoint by a microservice which the internal service is authorized, you need to use client-credentials flow to make a request to the related microservice.
• If your service is not authorized, you can use Integration services.

The suggested way is to write integration services spesifically for the related microservice interactions. You can check the Integration Services documentation.

I will update the documentation to include the integration services aswell.

Hello cangunaydin,

Basically, the IDataSeeder (https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Data/Volo/Abp/Data/DataSeeder.cs) finds all the related IDataSeedContributors in the DI container and runs the SeedAsync method.

Some of the modules need some initial data in order to operate. Hence, they have their own DataSeedContributor, like IdentityDataSeedContributor or PermissionDataSeedContributor. Or you may have your own business related DataSeedContributor. All of these DataSeedContributors are added to DI and seeded via IDataSeeder. Notice that all of them are located under the Domain layer of the layered architectured module (or the application).

In the monolith applications, IDataSeeder seeds the modules' DataSeedContributors because they are directly or indirectly referenced to the Domain of that module. That means they are already registered to the Dependency Injection Container.

However in a microservice architecture, the modules are seperated into different microservices. All the microservices doesn't have references to all the modules. That's why you need to create different DataSeeders (like the IdentityDataSeeder in your example) to handle the seeding manually.

First of all IdentityDataSeedContributor is basically the same with the application template. The idea is as you can see, to override the default AdminEmail and AdminPassword.

Second, Permissions are located under the Application.Contracts layer and the PermissionDefinitionProvider registers the permissions. Which means you need to find the permissions first to seed them.

In the microservice template, this is a sample of how the permissions are seeded in the AdministrationServiceDataSeeder:

public async Task SeedAsync(Guid? tenantId = null)
    {
        using (_currentTenant.Change(tenantId))
        {
            using (var uow = _unitOfWorkManager.Begin(requiresNew: true, isTransactional: true))
            {
                var multiTenancySide = tenantId == null
                    ? MultiTenancySides.Host
                    : MultiTenancySides.Tenant;

                var permissionNames = (await _permissionDefinitionManager
                    .GetPermissionsAsync())
                    .Where(p => p.MultiTenancySide.HasFlag(multiTenancySide))
                    .Where(p => !p.Providers.Any() || p.Providers.Contains(RolePermissionValueProvider.ProviderName))
                    .Select(p => p.Name)
                    .ToArray();
                
                _logger.LogInformation($"Seeding admin permissions.");
                await _permissionDataSeeder.SeedAsync(
                    RolePermissionValueProvider.ProviderName,
                    "admin",
                    permissionNames,
                    tenantId
                );
                
                _logger.LogInformation($"Seeding language data.");
                await _languageManagementDataSeeder.SeedAsync();

                await uow.CompleteAsync();
            }
        }
    }

Why? Because it is using dynamic permission store which means each microservice is writing their own permissions to the AdministrationService database directly and the dataseeder is granting these permissions. Otherwise, AdministrationService will need to reference to all the microservices' Application.Contracts layers (which it was, before we implemented the dynamic permission store).

See PermissionDataSeedContributor and PermissionDataSeeder for more details.

I think I see your point. The reason can be the PermissionDefinitionManager not able to find the permissions in the database yet because it would be running very first in the module initializations.

Can you make sure that the tenant permissions exist in the database when you run the dataseeder as you shared in the screenshot?

Hello,

You are using angular with separate auth-server template, it seems you have mis-configurations on docker-compose file.

We've detailed explanation about the environment variables when running on docker: https://docs.abp.io/en/commercial/latest/startup-templates/application/deployment-docker-compose?UI=NG&DB=EF&Tiered=Yes#bookstore-api

Please examine the samples and the generated docker-compose files when you've created a new template (or just create a new template to compare).

As far as I see, you receive the error when you make a request from front-end to back-end; the back-end tries to validate the token but can't reach to auth-server. Specifically, you are missing environment configuration for your docker back-end service based on the docker-compose file you've shared in your initial question.