Hello, We will try Mailkit. I think Abp should move away from using the default smtp email sending service since the smtp client is clearly not meant to be used this way.
That actually was my initial assumption, that it tries to receive the data from the database and the database query is actually the slowing factor here, but looking at our azure monitoring, there is no dependency to database so the execution does not (at least every time) go through the database.
I guess this has to be related to Redis somehow, but not in the way you described, if I understood correctly
Yes, we are using Redis already. My initial thought was that it cannot be the Redis, since we see no overload indicators in Azure Redis monitoring. However we see some intermittent timeout exceptions and in those I can see, if I understand correctly, some pretty high number of waiting calls (async-ops count), which could indicate some Redis overload.
Timeout awaiting response (outbound=0KiB, inbound=0KiB, 5859ms elapsed, timeout is 5000ms), command=EXPIRE, next: EXPIRE c:Volo.Abp.MultiTenancy.TenantConfiguration,k:SCM_PROD:i:dba2a1ba-5a58-f4f6-ec6a-3a03f2c223b2,n:null, inst: 0, qu: 0, qs: 0, aw: False, bw: SpinningDown, rs: DequeueResult, ws: Idle, in: 0, last-in: 0, cur-in: 63, sync-ops: 19115, **async-ops: 1215359**, serverEndpoint: redis-paas-PROD-002.redis.cache.windows.net:6380, conn-sec: 27571.89, aoc: 0, mc: 1/1/0, mgr: 9 of 10 available, clientName: AW0SDWK000002(SE.Redis-v2.7.27.49176), IOCP: (Busy=0,Free=1000,Min=1,Max=1000), WORKER: (Busy=30,Free=32737,Min=2,Max=32767), POOL: (Threads=30,QueuedItems=4,CompletedItems=3836531,Timers=54), v: 2.7.27.49176 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)
Is there any solution for the localization problem? Is this a known problem or are we missing something here?
Can you please shed some light to the problems that we are facing. The main problem is that the dynamic configuration service's "Configure" method is never called. How is the structure supposed to work? When we are debugging the login, when is the execution supposed to call the configure method: when the tenant is changes from the login page **or ** when the "Login with Azure AD" -button is clicked? As the configure is called in neither case, what could be the problem here?
OK, thanks!
Thanks, we will try to implement this. How the "AddOpenIdConnect" part should go in this case, where the configuration is defined dynamically? Here is a general example how that normally goes.
context.Services.AddAuthentication()
.AddOpenIdConnect("ABP2AzureADScheme", "Logon with Azure AD", options =>
{
options.Authority = configuration["AzureAd:Instance"] + configuration["AzureAd:TenantId"] + "/v2.0/";
options.ClientId = configuration["AzureAd:ClientId"];
options.ResponseType = OpenIdConnectResponseType.CodeIdToken;
options.CallbackPath = configuration["AzureAd:CallbackPath"];
options.ClientSecret = configuration["AzureAd:ClientSecret"];
options.RequireHttpsMetadata = false;
options.SaveTokens = true;
options.GetClaimsFromUserInfoEndpoint = true;
options.Scope.Add("email");
options.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "sub");
});
Thanks for the answer! We are aiming to enable Microsoft Entra Id SSO login for some of our customers, that use our (Abp) application. How is that going to work when we cannot configure the azure tenant in the tenant's external login provider configuration? If only the client id and the secret are configurable, how can the customer point the configuration to their Microsoft Entra Id?
Hi alper, thank you for the answer. There is a difference whether a service is down once every couple of years or once every couple of months. Anyway, I had forgotten about the local nuget cache. Of course we can use that as the source and push the packages to our Azure Artifacts feed. Thanks for the tip!
It turns out that abp has made custom nuget package source(some bicycle), which works like a xmas tree. Not a first time and not a last one when it's down, I assume. If you use a azure devops I would highly recommend to enable custom artifact feed. It has built-in capabilities to Azure devops and forward restores to it.
You cannot use custom feed for nuget packages in Azure Artifacts. That's why I suggested a method to enable package loading from the abp nuget server. If this was possible, we could download the packages and push them to Azure Artifacts feed (or where ever). Seems like MS is not going to implement the custom nuget feed capability any time soon.
