Hi
I can see BulkPermissionStore is working — cache hits are showing correctly. But the warm cache time (1954ms) is still high, which tells me there's more we can optimize.
A few questions about this environment:
This is a different production environment from the one we tested earlier (which showed 682ms), right? How many production environments do you have?
I see 8389 granted permissions for the R:admin role — that's significantly more than your other environment. Is this expected? Do different environments have different permission configurations?
Did you deploy all 4 files we provided to this environment? Specifically:
BulkPermissionStore.cs (the updated version with IsGrantedAsync override)PermissionGrantBulkCacheItem.csPermissionGrantBulkCacheItemInvalidator.csOptimizedPermissionChecker.cs ← this one is criticalThe OptimizedPermissionChecker.cs handles the application-layer optimization. Without it, even with BulkPermissionStore working, 8389 permissions will still cause ~2 seconds of processing overhead. Could you check if this file is included and properly registered?
How many microservices are running in this environment? Is it the same architecture as the other production?
What are the server specs (CPU/RAM) for this environment compared to your other production and local?
Could you also share the warm cache log from your first production environment (the one that showed 682ms) for comparison? I want to confirm that environment has all 4 files working.
Thanks
Hi,
This is a known issue — static CSS files like global-styles.css can't resolve PathBase because they have no server-side context. Neither root-absolute (/images/...) nor relative (images/...) paths work reliably across all bundling modes when hosted under a sub-path.
The workaround is to move these CSS variable definitions from the static file to a server-rendered Layout Hook, where Url.Content("~/...") properly respects PathBase.
Here's how:
1. Create a ViewComponent:
using Microsoft.AspNetCore.Mvc;
using Volo.Abp.AspNetCore.Mvc;
public class PathBaseStyleViewComponent : AbpViewComponent
{
public IViewComponentResult Invoke()
{
return View("~/Views/Shared/Components/PathBaseStyle/Default.cshtml");
}
}
2. Create the Razor view (Views/Shared/Components/PathBaseStyle/Default.cshtml):
<style>
:root {
--lpx-logo: url('@Url.Content("~/images/logo/leptonx/icon.svg")');
--lpx-logo-icon: url('@Url.Content("~/images/logo/leptonx/icon.svg")');
--lpx-theme-light-bg: url('@Url.Content("~/LeptonX/images/login-pages/login-bg-img-light.svg")');
--lpx-theme-dim-bg: url('@Url.Content("~/LeptonX/images/login-pages/login-bg-img-dim.svg")');
--lpx-theme-dark-bg: url('@Url.Content("~/LeptonX/images/login-pages/login-bg-img-dark.svg")');
}
</style>
3. Register the hook in your module:
Configure<AbpLayoutHookOptions>(options =>
{
options.Add(LayoutHooks.Head.Last, typeof(PathBaseStyleViewComponent));
});
4. Remove the CSS variable definitions from global-styles.css (the --lpx-logo, --lpx-logo-icon, and --lpx-theme-*-bg declarations). Keep the file if you have other custom styles in it.
With this approach, Url.Content("~/...") generates the correct path (e.g. /server/images/logo/leptonx/icon.svg) regardless of your PathBase configuration.
We're also looking into updating the LeptonX layouts to handle this internally so it works out of the box in future versions.
Thanks
Hi,
The error UNABLE_TO_VERIFY_LEAF_SIGNATURE is a Node.js SSL/TLS certificate chain verification error. This is not related to ABP or OpenIddict authentication — it means Node.js cannot verify the SSL certificate of your backend server during SSR requests.
To help confirm the root cause, could you provide some details:
NODE_TLS_REJECT_UNAUTHORIZED=0 before starting your SSR server make the error go away? (This is only for testing, not a production solution.)Thanks
Hi
replaceableComponents.add() is still working in v10, the API hasn't changed.
Since you're jumping from v8 to v10, there's a good chance the issue is related to the Angular 19 standalone migration rather than the replacement mechanism itself.
Could you share your app.config.ts, full app.component.ts, and one of your custom components (e.g. BreadcrumbComponent)? Also check if there are any errors in the browser console.
I'll try to reproduce the issue on my end once I see your setup.
Thanks
Alright, if you run into any other issues, just let me know.
Thanks.
Thank you. We will review your new question as soon as possible. 👍
Hi,
No problem at all. You can add the additional Web project at any time, even after the existing solution is complete. The new Web project is just an independent UI entry point — it won't affect your existing AuthServer, HttpApi.Host, or the admin-side Web project in any way.
Just follow the steps we discussed earlier (register a new OIDC client, configure URLs, add CORS, etc.) and it will work the same regardless of when you add it.
Thanks
hi
Can you create a new question for your new case?
Thanks.
Hi,
Thanks for the detailed report. This is a confirmed bug — when we removed the jquery-form package dependency and deleted JQueryFormScriptContributor in ABP 10.2, we missed updating the 4 JS files in the CmsKit module that still call ajaxSubmit().
We've already fixed this. The fix replaces ajaxSubmit() with abp.ajax() + FormData in those files. It will be included in the next patch release.
As a temporary workaround, you can manually add jquery-form back to the global bundle since the file is still physically present in your project:
Configure<AbpBundlingOptions>(options =>
{
options.ScriptBundles.Configure(
StandardBundles.Scripts.Global,
bundle =>
{
bundle.AddFiles("/libs/jquery-form/jquery.form.min.js");
});
});
Thanks