Please share the related logs of your
In the MVC/BlazorServer apps, you can see a configuration as below under the OpenIdConnect configuration:
if (Convert.ToBoolean(configuration["AuthServer:IsOnK8s"]))
{
context.Services.Configure<OpenIdConnectOptions>("oidc", options =>
{
options.MetadataAddress = configuration["AuthServer:MetaAddress"]!.EnsureEndsWith('/') +
".well-known/openid-configuration";
var previousOnRedirectToIdentityProvider = options.Events.OnRedirectToIdentityProvider;
options.Events.OnRedirectToIdentityProvider = async ctx =>
{
// Intercept the redirection so the browser navigates to the right URL in your host
ctx.ProtocolMessage.IssuerAddress = configuration["AuthServer:Authority"]!.EnsureEndsWith('/') + "connect/authorize";
if (previousOnRedirectToIdentityProvider != null)
{
await previousOnRedirectToIdentityProvider(ctx);
}
};
var previousOnRedirectToIdentityProviderForSignOut = options.Events.OnRedirectToIdentityProviderForSignOut;
options.Events.OnRedirectToIdentityProviderForSignOut = async ctx =>
{
// Intercept the redirection for signout so the browser navigates to the right URL in your host
ctx.ProtocolMessage.IssuerAddress = configuration["AuthServer:Authority"]!.EnsureEndsWith('/') + "connect/logout";
if (previousOnRedirectToIdentityProviderForSignOut != null)
{
await previousOnRedirectToIdentityProviderForSignOut(ctx);
}
};
});
You should be setting [AuthServer:IsOnK8s] to true since you are running it on containers; which means you will be logging in through the browser but obtaining/validating the tokens through the internal network.
Set the [AuthServerMetaAddress] to real DNS.
Set the [AuthServerMetaAddress] to internal docker service address.
And by the way, if you are preparing the sample try to deploy to production cluster not to local one, because the manifests configuration usually are different. It could work local but not in production. We already face such problems.
Thanks & Regards,
Well, I can not deploy to production cluster. But there shouldn't be any differences between the local cluster other then DNS mapping and SSL generation.
We will be publishing eShopOnAbp with the new version soon. But this issue is not related to ABP but the .NET 8 itself. Hence, I would suggest checking SO aswell. There should be others having the same problem already.
It seems you are trying to run your application on HTTPS inside the internal error that causes the problem. Try removing all the 443 exposing and run the application on HTTP. Ingress should handle the internal port HTTPS mapping.
I'll try to create a public sample for .NET 8 local k8s deployment.
Hi, Do these links help to solve your problem?
We have application deployment guide for Azure at https://docs.abp.io/en/commercial/latest/startup-templates/application/azure-deployment/azure-deployment?UI=MVC&DB=EF&Tiered=No but we don't have a step by step guide for microservice template deployment to Azure simply because it is not really related to ABP framework and we don't have enough knowledge.
You can share the log information about the error you come across after deployment when you navigated to your application to diagnose the problem better. Otherwise, a screenshot of an Azure Services (or AWS or Google KS etc) because those platforms are not in our expertise.
Yes, you need to re-generate proxy for the SaasService since you have a new endpoint now. See https://docs.abp.io/en/abp/latest/API/Static-CSharp-API-Clients#without-contracts for more information.
When you make a request from /Forms/CreateModal, it is from the UI right? It is the back-office application (web/blazor/angular whatever).
So, you are making a request from the application to the related microservice through the web gateway. It is not microservice-to-microservice communication. It is a client-server request.
When you make a request from the FormsService to SaasService (or vice versa) it is the microservice-to-microservice communication. When making this kind of request, there is no gateway interaction. They directly make request to each other (if you are using synchronous communication).
Hello,
This is from CSharp Api Clients.
Without using the ABP, what we normally do is; we create an HTTPClient and serialize request and make the request to the url of the microservice that we should already be aware of. Then deserialize the result and use it.
What ABP provides is the HttpApi.Client layer which contains information (via the static proxy) about the ApplicationService interface with the related DTOs. So, when you reference to the HttpApi.Client layer of a microservice from an other microservice, you can use the application services without worrying about deserializing, dto duplicating or versioning.
Ideally, you can publish the HttpApi.Client projects as nuget packages to your private nuget server to decouple it. It will also provide versioning when you start using it as PackageReference instead of ProjectReference.
This is the design and you can learn more on https://docs.abp.io/en/abp/latest/Best-Practices/Module-Architecture.
You are also free not to use it though.
As you can see from the documentation, all the requests from the applications are redirected to the related gateway to be re-routed to the related microservice.
When you are making a request from the back-office application (blazor app) it redirects to the WebGateway (localhost:44325). When you make a request from the public-web application, it will redirect to the PublicWebGateway (localhost:44353). Then you need to configure the re-routing from the gateways to the related microservices. More information is at https://docs.abp.io/en/commercial/latest/startup-templates/microservice/gateways
By the way, the scenario you explained is not related to communication between microservices.