Current behavior (ABP v9.1.1, Angular): Idle Session Timeout works per-tab. The built-in Account Idle Session Timeout feature does not synchronize timers across multiple open tabs/windows by default. Each tab runs its own activity watcher and countdown. This is why you observe inconsistent behavior across tabs.
Implement multi‑tab sync (Angular) using storage events:
Example implementation outline:
// src/app/core/idle-sync.service.ts
import { Injectable, NgZone } from '@angular/core';
const CHANNEL_KEY = 'abp-idle-sync';
type IdleSyncMessage =
| { t: 'activity'; ts: number }
| { t: 'show-warning'; deadline: number }
| { t: 'cancel-warning' }
| { t: 'timeout' };
@Injectable({ providedIn: 'root' })
export class IdleSyncService {
constructor(private zone: NgZone) {
window.addEventListener('storage', (e) => {
if (e.key !== CHANNEL_KEY || !e.newValue) return;
const msg = JSON.parse(e.newValue) as IdleSyncMessage;
this.zone.run(() => this.onMessage?.(msg));
});
}
onMessage?: (msg: IdleSyncMessage) => void;
notify(msg: IdleSyncMessage) {
// write-then-remove to trigger storage event in other tabs
localStorage.setItem(CHANNEL_KEY, JSON.stringify(msg));
localStorage.removeItem(CHANNEL_KEY);
}
}
Example:
// src/app/app.component.ts
import { Component, HostListener, OnInit } from '@angular/core';
import { IdleSyncService } from './core/idle-sync.service';
import { AccountIdleSessionTimeoutService } from '@abp/ng.account/config'; // service used internally by ABP Account Angular UI
@Component({ selector: 'app-root', template: '<router-outlet></router-outlet>' })
export class AppComponent implements OnInit {
constructor(
private idleSync: IdleSyncService,
private idleService: AccountIdleSessionTimeoutService
) {}
ngOnInit() {
// 1) When local idle feature is about to show warning, broadcast to others
this.idleService.onShowWarning$.subscribe((deadlineUtcMs) => {
this.idleSync.notify({ t: 'show-warning', deadline: deadlineUtcMs });
});
// 2) When local warning is cancelled (user activity), broadcast
this.idleService.onCancelWarning$.subscribe(() => {
this.idleSync.notify({ t: 'cancel-warning' });
});
// 3) When local timeout happens (logout), broadcast
this.idleService.onTimeout$.subscribe(() => {
this.idleSync.notify({ t: 'timeout' });
});
// 4) React to messages from other tabs
this.idleSync.onMessage = (msg) => {
switch (msg.t) {
case 'activity':
this.idleService.resetTimerFromExternalActivity(); // custom helper; see below
break;
case 'show-warning':
this.idleService.showWarningExternally(msg.deadline);
break;
case 'cancel-warning':
this.idleService.cancelWarningExternally();
break;
case 'timeout':
this.idleService.triggerTimeoutExternally();
break;
}
};
}
// Broadcast user activity from this tab
@HostListener('document:mousemove')
@HostListener('document:keydown')
@HostListener('document:click')
onActivity() {
this.idleSync.notify({ t: 'activity', ts: Date.now() });
}
}
If the ABP Angular Account idle service you use doesn’t expose such methods, wrap/extend it where you already subscribe to its events (warning start/cancel, timeout). The idea is to:
Notes:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
ABP’s Idle Session Timeout feature already works across multiple tabs of the same browser profile. It uses browser storage and a single activity monitor to keep all tabs in sync: user activity in any tab resets the idle timer, and when the warning/timeout is reached, all tabs react consistently.
To enable and configure it in Angular (v9.1.1):
If you want to customize behavior:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
A) Keep using the header, but allow underscores through your ingress
For NGINX Ingress Controller:
For plain NGINX (not ingress), ensure:
underscores_in_headers on;
and don’t use ignore_invalid_headers on; (or set off)
Reference config snippet: server { listen 443 ssl; server_name auth.mycompany.com;
underscores_in_headers on;
# ignore_invalid_headers off; # if you have it on, headers with underscore are dropped
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://auth-server-svc;
}
}
Ensure your ABP app still has the header resolver enabled (it is by default): Configure<AbpTenantResolveOptions>(options => { options.AddHeaderTenantResolver(); // default uses "__tenant" });
Then you can request tokens with the header set: POST https://auth.mycompany.com/connect/token Headers: __tenant: my-tenant Content-Type: application/x-www-form-urlencoded Body: grant_type=password&client_id=...&client_secret=...&username=...&password=...
B) Avoid the header; use domain or query string based tenant resolution If your ingress cannot be changed, switch to a resolver that does not use underscores.
Subdomain/domain based resolution:
Query string fallback (for non-browser/token scenarios):
Important ABP middleware order (for the token endpoint and all APIs)
Quick verification checklist
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
Fix it by verifying and applying the steps below:
Confirm the RemoteRefreshUrl and BaseUrl
Put MultiTenancy and Authentication in correct middleware order (server apps)
Check proxy/gateway and CORS
Kubernetes/NGINX specifics
Increase/override the distributed HTTP client timeout (optional)
Configure<AbpHttpClientBuilderOptions>(options =>
{
options.ProxyClientBuildActions.Add((remoteServiceName, client) =>
{
if (remoteServiceName == "Default" || remoteServiceName == "AuthServer")
{
client.Timeout = TimeSpan.FromSeconds(300);
}
});
});
This should not replace fixing connectivity, but helps if your auth service occasionally takes longer.
Configure<AbpClaimsPrincipalFactoryOptions>(opts =>
{
opts.IsDynamicClaimsEnabled = false;
});
Alternatively, provide your own IAbpDynamicClaimsPrincipalContributor that doesn’t call remote. Only use as a diagnostic step.
Blazor WASM specifics
React Native specifics
If the above is correctly configured and you still see refresh timeouts:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
public class MyAppService : ApplicationService
{
private readonly IBackgroundJobManager _backgroundJobManager;
public MyAppService(IBackgroundJobManager backgroundJobManager)
{
_backgroundJobManager = backgroundJobManager;
}
[UnitOfWork]
public virtual async Task DoSomethingAsync()
{
// 1) Perform your data changes here
// await _repository.InsertAsync(entity);
// 2) Register callback to run only if the UoW commits
CurrentUnitOfWork.OnCompleted(async () =>
{
await _backgroundJobManager.EnqueueAsync(
new MyJobArgs { /* ... */ }
);
});
}
}
EnqueueAsync runs after the transaction has been committed. If the UoW rolls back, the callback isn’t executed, so no Hangfire job is created.
Use domain events + transactional outbox (for cross-context/microservices)
Notes:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
What you observe is by design in ABP Framework versions before 8.3. In AbpDbContext.PublishEventsForTrackedEntity, ABP intentionally skips “updated” entity events and ABP concept application when only foreign key properties are modified:
Reason: This optimization existed to avoid firing update logic when only relationship fixups (FK changes) happen and the entity’s own scalar properties didn’t change.
Starting from ABP 8.3, this behavior was changed: ABP applies auditing/concurrency updates when a navigation property changes. That means LastModificationTime, LastModifierId, ConcurrencyStamp and EntityVersion are updated when navigation (and thus FK) changes are detected.
Your project is on ABP 9.1.3, which already includes that change. To ensure it’s active:
Configure<AbpEntityChangeOptions>(o =>
{
o.PublishEntityUpdatedEventWhenNavigationChanges = true; // default
});
Configure<AbpAuditingOptions>(options =>
{
options.EntityHistorySelectors.AddAllEntities();
});
Note: Even without entity history, the LastModificationTime should be set by ApplyAbpConcepts once navigation/FK changes are considered updates.
If you must keep older behavior (pre-8.3) or selectively control it:
Summary action items for your case:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
Notes
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
Root cause: You created a minimal app with only AbpEmailingModule. The setting system throws “Undefined setting: Abp.Mailing.DefaultFromAddress” because the Email settings are defined by the Emailing module but are registered through module initialization and typically read from configuration/setting stores. In a console app created this way, you must:
Fix (recommended simple approach): Add an appsettings.json next to your console app and load it when creating the application so ABP’s configuration system can populate settings.
using Microsoft.Extensions.Configuration;
using Volo.Abp;
using Volo.Abp.Emailing;
using Volo.Abp.Settings;
internal class Program
{
private static async Task Main(string[] args)
{
// Build configuration that includes appsettings.json
var configuration = new ConfigurationBuilder()
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: false)
.AddEnvironmentVariables()
.Build();
// Create Abp application with the configuration
using var app = await AbpApplicationFactory.CreateAsync<AbpEmailingModule>(options =>
{
options.Services.ReplaceConfiguration(configuration);
});
await app.InitializeAsync();
var settingProvider = app.ServiceProvider.GetRequiredService<ISettingProvider>();
// Now this will work if setting exists in config or store
var from = await settingProvider.GetOrNullAsync(EmailSettingNames.DefaultFromAddress);
Console.WriteLine(from ?? "No value found");
}
}
appsettings.json:
{
"Settings": {
"Abp.Mailing.DefaultFromAddress": "noreply@yourapp.com",
"Abp.Mailing.DefaultFromDisplayName": "Your App",
"Abp.Mailing.Smtp.Host": "127.0.0.1",
"Abp.Mailing.Smtp.Port": "25",
"Abp.Mailing.Smtp.UseDefaultCredentials": "true"
}
}
var settingManager = app.ServiceProvider.GetRequiredService<ISettingManager>();
await settingManager.SetGlobalAsync(EmailSettingNames.DefaultFromAddress, "noreply@yourapp.com");
var from2 = await settingProvider.GetOrNullAsync(EmailSettingNames.DefaultFromAddress);
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
Practical options and how to proceed:
Configure<AbpBundlingOptions>(options =>
{
options.StyleBundles.Configure(BlazorLeptonXThemeBundles.Styles.Global, bundle =>
{
bundle.AddFiles("/css/custom-leptonx-overrides.css");
});
});
Then, in custom-leptonx-overrides.css:
:root {
--lpx-brand: #4f46e5;
--lpx-primary: #4f46e5;
--bs-primary: #4f46e5;
}
[data-bs-theme="dark"] {
--lpx-brand: #8b5cf6;
}
For Angular:
Mobile (Expo/React Native):
Alternatives to ABP themes:
Guidance when building your own theme:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
