Activities of "gterdem"

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.

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?

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.

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.

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,

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.

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

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

Both public web app and the BlazorServer back-office (administration) application are using the same application configuration edpoints to get initial data.

These are Application configuration scripts and application localization scripts which are used for authentication (current user info etc), features, settings, multi-tenancy information and localization information respectively.

These information are cached to improve performance and shared. That's why dedicated caching server (redis) is being used.

Hello,

There is no standard way of handling background jobs when talking about microservices. You can let each microservice to handle their own background jobs. Or create a new microservice (essentially a console application) dedicated to handle all the background jobs.

Advantages and disadvantages are based on your use cases.

Okay, now I understand.

First, for microservice-to-microservice calls, we introduced Integration Services. We strongly recomment using integration services for this kind of usage.

If you want to keep using existing authorized endpoints, you probably have IdentityClient configuration as below:

"IdentityClients": {
    "Default": {
      "GrantType": "client_credentials", 
      "ClientId": "BookStore_OrderService",
      "ClientSecret": "1q2w3e*",
      "Authority": "https://localhost:44322", -> On production this must be the internal service name
      "Scope": "ProductService"
    }
  }

Instead of using https://10.200.40.25:44322 try using docker service name something like http://myauthservice.

The token validation etc should be (will be) done through the internal network.