Activities of "maliming"

Hi,

Not for this one. The discovery request isn't reaching OpenIddict at all, so nothing is read from those tables yet. They come into play once the endpoints respond: the discovery document lists the scopes from OpenIddictScopes, and OpenIddictApplications is checked on the authorize/token calls of your Angular client. Leave them as they are for now.

Thanks

Hi,

Thanks for the logs. The identity task itself is where to look. The GET /.well-known/openid-configuration in the identity log arrives with the exact path and still ends with "reached the end of the middleware pipeline" after 0.1 ms. With the standard OpenIddict setup, the OpenIddict handler in UseAuthentication takes that request and writes the response itself, so it never gets to that 404. Add /Account/Login returning 404 on localhost inside the container, and what runs in that task isn't wired up like your local run: the OpenIddict server isn't handling requests there and the Account pages aren't mapped.

To see why, send me these from the identity host:

1. Program.cs
2. The complete host module class, the one with OnApplicationInitialization
3. The .csproj of that project
4. The ECS task definition for that container: image tag, entry point/command and container port
5. The task's startup log from process start to the first request, without a filter on the log category
6. From inside the container, the full response of a request to /.well-known/openid-configuration on the local port, headers included

Thanks

Hi,

We've refunded your ticket, this one is on us.

Thanks

Hi,

The Angular sources are missing from both CMS Kit source code archives. That's a packaging bug on our side and we'll fix it.

@abp/ng.cms-kit is open source, you can take it from GitHub right away:

https://github.com/abpframework/abp/tree/10.6.0/npm/ng-packs/packages/cms-kit

For @volo/abp.ng.cms-kit-pro, drop me an email at liming.ma@volosoft.com with the version you need and I'll send you the Angular sources until the archives are fixed.

One note, both packages start with 10.2.0, there is no CMS Kit Angular package on 10.0.1.

Thanks

Hi,

A 404 for /.well-known/openid-configuration isn't something the AuthServer produces by itself. When a request with that path reaches it, OpenIddict handles it, it doesn't fall through to a 404, and a CORS preflight for it is answered by the CORS middleware or by OpenIddict, again not with a 404. So the 404 means the request didn't reach the AuthServer, reached it with a different path, or reached a different service. The 504 is API Gateway not getting a response from the integration in time.

So start with the API Gateway route for this path. It needs the same integration as /Account/Login, and OPTIONS has to be covered too, either forwarded or answered by the gateway's CORS config, because the browser sends a preflight for this URL (the screenshot in https://abp.io/support/questions/10858/ shows that OPTIONS request getting the 404).

The AuthServer log tells you which side it is. Search the logs of all tasks for one failing request:

Request starting ... /.well-known/openid-configuration
Request finished ... /.well-known/openid-configuration - <status> ...

• No Request starting line: the request never reached the AuthServer, fix the route/integration.
• The line is there but with a different path, or the app itself answered 404: the gateway rewrites the path, or that ECS service doesn't host OpenIddict. When OpenIddict does pick up the path it also logs The request URI matched a server endpoint: Configuration.
• 400 with "This server only accepts HTTPS requests": the task receives plain HTTP after TLS termination at the gateway. If your module still has the template's AuthServer:RequireHttpsMetadata check, set it to false in the DEV appsettings. If that part was removed, add this to ConfigureServices:

using OpenIddict.Server.AspNetCore;

Configure<OpenIddictServerAspNetCoreOptions>(options =>
{
    options.DisableTransportSecurityRequirement = true;
});

• Request finished with 200 in a few ms while the public URL gets 504: the problem is between API Gateway and the task, check the API Gateway access log and the integration latency for that request. No Request finished at all: the app is hanging on that request, and the lines before it show on what.

Send the AuthServer log around one failing request, the API Gateway log for the same request, and the route/integration config for this path to liming.ma@volosoft.com and we'll go through it with you.

Thanks

Hi,

The error is about the user, not about the tenant settings. Enabling two factor for a user requires that user to already have a usable verification provider, and there are three:

• Email, available once Email confirmed is set on the user
• SMS, available once Phone number confirmed is set (and you have an SMS provider)
• Authenticator app, which the user sets up themselves from My account > Authenticator app

You can set the first two from Identity management > Users > Actions > Edit, the Email confirmed and Phone number confirmed checkboxes are there. Once a user has one of them the Two factor modal saves fine. Saving the tenant's Two factor settings doesn't change anything here, that check only looks at the user.

Forced and Disabled do work, they just don't rewrite the per user flag. The behaviour is applied when the user signs in, while the Enable two-factor column in the user list is the per user setting, which only has an effect when the behaviour is Optional. So the column keeps whatever value it had. Two things tell you the setting is in effect: the Two factor item disappears from the Actions menu for every user, and if you log in as one of them you get the verification step even though the column still shows a cross.

One thing to sort out before you switch to Forced: a user with no confirmed email, no confirmed phone number and no authenticator can't log in at all, they get sent to the confirm email/phone page first. Only one user in your list has a confirmed email address, so confirm the others before you turn it on.

Thanks

Hi,

Volo.Abp.TextTemplating.Scriban 10.0.0 is compiled against Scriban 6.x, so bumping only the Scriban package to 7.x makes template rendering fail at runtime with TypeLoadException: Could not load type 'Scriban.Parsing.ParserOptions' ... due to value type mismatch. That's the email error you're hitting.

There are three ways out, depending on how far you want to go.

If you just need the audit to stop failing the build, keep Scriban 6.3.0 and suppress the advisories. 6.3.0 is flagged by 14 of them right now, so the list is long:

<ItemGroup>
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-5wr9-m6jw-xx44" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-24c8-4792-22hx" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-7jvp-hj45-2f2m" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-c875-h985-hvrc" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-grr9-747v-xvcp" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-p6q4-fgr8-vx4p" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-v66j-x4hw-fv9g" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-wgh7-7m3c-fx25" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-x6m9-38vm-2xhf" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-xcx6-vp38-8hr5" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-5rpf-x9jg-8j5p" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-m2p3-hwv5-xpqw" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-q6rr-fm2g-g5x8" />
  <NuGetAuditSuppress Include="https://github.com/advisories/GHSA-xw6w-9jjh-p9cr" />
</ItemGroup>

If you want the patched Scriban while staying on ABP 10.0, pin it:

<PackageReference Include="Scriban" Version="7.2.5" />

and override the rendering engine in your own project:

using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.Extensions.Localization;
using Scriban;
using Volo.Abp.DependencyInjection;
using Volo.Abp.TextTemplating;
using Volo.Abp.TextTemplating.Scriban;

[Dependency(ReplaceServices = true)]
[ExposeServices(typeof(ScribanTemplateRenderingEngine))]
public class MyScribanTemplateRenderingEngine : ScribanTemplateRenderingEngine
{
    public MyScribanTemplateRenderingEngine(
        ITemplateDefinitionManager templateDefinitionManager,
        ITemplateContentProvider templateContentProvider,
        IStringLocalizerFactory stringLocalizerFactory)
        : base(templateDefinitionManager, templateContentProvider, stringLocalizerFactory)
    {
    }

    protected override async Task<string> RenderTemplateContentWithScribanAsync(
        TemplateDefinition templateDefinition,
        string templateContent,
        Dictionary<string, object> globalContext,
        object? model = null)
    {
        var context = CreateScribanTemplateContext(templateDefinition, globalContext, model);
        return await Template.Parse(templateContent).RenderAsync(context);
    }
}

One thing to watch here: if your solution uses the Docs module, it parses Scriban templates on its own and the override doesn't cover it, so document rendering breaks the same way.

The permanent fix is upgrading ABP. Scriban was bumped along the 10.x line:

| ABP | Scriban | | --- | --- | | 10.2.0 | 7.0.0 | | 10.4.1, 10.5.0 | 7.2.1 | | 10.6.0 | 7.2.5 |

7.2.5 has no open advisories, so on ABP 10.6.0 the warning is gone and you need neither the suppressions nor the override.

Thanks

Hi,

You can stay on 10.4. This requires one controlled conversion for Worker and CompanyRepresentative, not manual relationship changes after every future regeneration of these entities.

Do not apply the current migration. Please send the generated migration and Git diff, or invite https://github.com/maliming to a private repository. I will prepare and check the exact patch that:

• replaces the join-table drop/create operations with data-preserving renames;
• removes the obsolete join entity files and updates the affected method calls;
• aligns the affected test seed GUID references.

After this one-time conversion, Suite 10.4 will keep the new naming when these entities are regenerated again. While using Suite 10.4, turn off Create tests when regenerating existing entities so their test GUIDs are not generated again. Newly created entities already use the current naming.

Thanks

: )

Hi,

The description alone isn't enough to tell which step got stuck. Every step of an agent run (model response, shell commands, starting applications, the package analysis on the first message) has its own timeout, and a timeout shows up as an error instead of staying at Running, so we need the log to see what happened.

Could you send this file to liming.ma@volosoft.com:

• Windows: %USERPROFILE%\.abp\studio\ui\logs\abp-studio-ui-logs.txt
• macOS / Linux: ~/.abp/studio/ui/logs/abp-studio-ui-logs.txt

And a few details:

1. Operating system and version.
2. The provider and model selected under Settings > Models (OpenRouter / OpenAI / Anthropic / custom).
3. What the task asked the agent to do, and the status text shown above the chat input while it was stuck (Thinking... / Running: xxx / Updating analysis...).
4. Whether this was the first message of a new session, and roughly how many packages the solution has.

About the lost session: a new session is only written to .abpstudio/agents.db under the solution folder after its first turn completes. If the turn is stopped or Studio is closed before that, nothing is saved and the session won't show up in Archive either. We'll change this.

Thanks