Activities of "gterdem"

It's probably your Identityserver is not running on https or not redirecting to https. Make sure running IdentityServer on https.

Hello,

Microservice template has 3 applications:

  1. Back-office/admin application (that can be blazor, angular or mvc)
  2. Public / landing page application. This is a RazorPage/MVC application
  3. Authserver / Identityserver application. This application hosts the login/register and user profile related pages.

You can make UI developments for all of these applications.

There are 2 ways to develop UI for microservices; Modular and Monolith. You can check adding ui to apps documentation about these ways.

Can you share what exactly you're trying to achieve and what seems not working?

Thanks for your response gterdem. We added required references which you described. Then, how can we use MicroserviceA.HttpApi.Client from MicroserviceB.Application layer (like MicroserviceB.Application.OrderAppService) for requesting MicroserviceA application service (like MicroserviceA.Application.ProductAppService)?

It would be great if you describe with some psuedo code. ScreenShot from code attached below:

Thanks.

Inject IContentService located inside ContentService.Application.Contracts that you have already referenced and use it like your own. Only caveat here is:

  1. Add ContentService.Http.Api.Client project reference as well (since IContentService implementation doesn't exist and it will be a remote service call) and it's appsettings configuration.
  2. If your ContentService is authorized with permission, grant that permission from IdentityServer Management UI or from IdentityServerDataSeeder like below:

<br>

await CreateClientAsync(
    name: "FinanceService", // Your client Id.
    scopes: commonScopes.Union(new[]
    {
        "ContentService"    //Allowed API scope
    }),
    grantTypes: new[] {"client_credentials"},
    secret: "1q2w3e*".Sha256(),     // The secret you use when making client_credential request
    permissions: new[] {ContentServicePermissions.XXX.Default}    // The permission you have over the method or appservice that you want to allow
);

The permissions parameters is the permission list you allow for this client.

Can you please describe intercommunication best practice between microservices?

As far as I know, there is no best practice in microservice inter-communication since it depends on your needs. But if there is, it is probably loosely coupled, event based communication. Using distributed event bus (message-broker) is much more favored and meaningfull in most of the cases.

We are using commercial microservice template, and trying to access from MicroserviceA to MicroserviceB at application layer. "gterdem" explained that, "Add the MicroserviceB.Application.Contracts project reference to MicroserviceA.Application.Contracts so that MicroserviceA application services become available in MicroserviceB.". We did it, but how can we send request (or access) to MicroserviceB application service method?

That is correct. ApplicationService located in MicroserviceA.Application.Contracts is looking for implementation. Since its implementation is hosted remotely, the missing piece is adding the MicroserviceA.HttpApi.Client project reference to MicroserviceB.HttpApi.Host. It will make your application make a remote service request configured in your application service like: <br>

"RemoteServices": {
  "Default": { 
    "BaseUrl": "https://localhost:44302/", //This must be Internalgateway endpoint
    "UseCurrentAccessToken": "false"
  }
},

You can observe the logs of your HttpApi.Host project to see if you have any problems related with IdentityServer.

To make this internal request work, you should have:

  1. Added MicroserviceB as a client that allows which api you are making a request to as shown in this answer
  2. Added Volo.Abp.Http.Client.IdentityModel.Web  nuget package to your MicroserviceA.HttpApi.Host project as shown in this answer
  3. Added Ocelot configuration in internal gateway appsettings

<br> I'll prepare a detailed guide or a community article about this soon. Don't forget to check the log if you come across any errors.

8a) Open Solution & from Services-> AdministrationService -> Right Click & added "OrderService.Application.Contracts.dll" by adding Project Reference (right click)

Can you try to update the csporj to use ProjectReference instead add dll file?

I tried adding the csproj project reference insteal dll files and when i am building the solution, its gving me the same error. Order service is not building properly. i have also updated the CLI & dot net to latest 4.4 version.

It is probably cached, try deleting bin/obj folders and add project reference instead of package reference and build with dotnet build /graphBuild.

Hello,

Only way to split the microservice solution to multiple repositories is to update the project references to package reference. It means publishing each package reference to a nuget server.

However, you can develop and store your microservices in individual repositories by duplicating shared microservice project functionalities. If you don't use tightly coupled communication between microservices (by referencing the Application.Contracts of an other microservice), it is possible to use different repositories for each microservice since microservices are independent from each other.

But the microservice solution is the big picture manually referencing the apps, gateways and microservice host projects to make it easier to control and manage over. You don't need to use microservice solution at all if you are already experienced in development of microservice systems.

Can you check the logs? Especially confirm that your redis server is up and running.

Thanks. Just for better clarity if any organization unit have multiple roles and multiple users are also added into organization unit then will user belongs to all the roles or only user role?

User doesn't belong to any role. User has permissions which are grouped as roles.

Your Organization-A may have RoleA, RoleB, RoleC. Your user may have RoleC. When you assign your user to Organization-A; user will have RoleA and RoleB too with RoleC.

Permission is based for authorization and roles represent group of permissions.

It is by design, there is no specific "organization role". You can define a role with the permissions you select and assign the role to a user or an organization. Whichever roles your user has (coming from organization unit or not), the permissions of the user are the unique combination of the permissions of the roles.

We have two microservices; Microservice A and Microservice B, in Microservice A, we want to call some application service at Microservice B via sending HTTP request to InternalGateway.

You can not make direct request to InternalGateway to reach Microservice X, you make request to Microservice X through InternalGateway. Gateway works as a service locator to redirect your requests to related microservice and it does it automatically.

1- Is there any way to get token from Microservice A (from comming request or anywhere else) for use at http request to InternalGateway?Or, what is the best practice for this purpose?

You don't get any token from microservice. Token provider is AuthServer and most of the flow is automatically done by identityServer. Add the MicroserviceB.Application.Contracts project reference to MicroserviceA.Application.Contracts so that MicroserviceA application services become available in MicroserviceB.

2- Another question; If we gain Token with the way described in this link, How we can store this Token related to user session(User can log in into multi device then we can't store in Dictionary or something like that)

You can not store any token in any user session because there is no session. Server to server communication doesn't involve any user.

You don't need to make http request to AuthServer manually to get access token. Add Volo.Abp.Http.Client.IdentityModel.Web nuget package to your MicroserviceA.HttpApi.Host project. This package will automatically make request to get access token and add it to request header as bearer token. Make appsettings configurations for this package in like: <br>

"IdentityClients": {
  "Default": {
    "GrantType": "client_credentials", // Don't change this
    "ClientId": "MicroserviceA",       // Caller
    "ClientSecret": "1q2w3e*",         // Secret you used when creating this client in IdentityServerDataSeeder
    "Authority": "https://myidentityserver.com", // AuthServer domain:port
    "Scope": "MicroserviceB"           // The resource you want to make request to 
  }
},

To make all of this work, you need to add MicroserviceA (makes the http request) as a client and MicroserviceB (the one you make the request to) as Api-Resource and Api-Scope. These configurations are done in IdentityServerDataSeeder file.

AdministrationService is also a client that makes request to IdentityService. You can check more about it in docs and in your template project. Here is how AdministrationService is configured as a client in IdentityServerDataSeeder just as example: <br>

//Administration Service Client
await CreateClientAsync(
    name: "AdministrationService", // Your client Id.
    scopes: commonScopes.Union(new[]
    {
        "IdentityService"    //Allowed API scope
    }),
    grantTypes: new[] {"client_credentials"},
    secret: "1q2w3e*".Sha256(),     // The secret you use when making client_credential request
    permissions: new[] {IdentityPermissions.Users.Default}    // The permission you have over the method or appservice that you want to allow
);

<br> Most of these subjects are related with IdentityServer and I suggest reading identity-server docs so that you can learn more about server-to-server (client_credential) communication and what abp helps about it.

Showing 531 to 540 of 726 entries
Made with ❤️ on ABP v9.2.0-preview. Updated on January 20, 2025, 10:27