hi Baytech
We will fix it in the next patch version. You can override the
IdentitySessionManagerto fix it. Thanks.
This fixes it. I don't like that solution though. Please fix it with a better solution in the next patch. Feels more like a band-aid solution than whatever the real fix is.
URGENT! Hi we upgraded to 9.0.0 and we are having issues logging out - one of the two revocat calls fails, leaving either the refresh or the access token alive, along with the application cookie. So when I log out, I just hit the login button and it auto logs me back in - no need for credentials. This is a GINORMOUS security concern. There is an error on the backend auth server every time this happens:
An unhandled exception has occurred while executing the request.
Volo.Abp.Data.AbpDbConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions.
---> Microsoft.EntityFrameworkCore.DbUpdateConcurrencyException: The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions.
at Npgsql.EntityFrameworkCore.PostgreSQL.Update.Internal.NpgsqlModificationCommandBatch.ThrowAggregateUpdateConcurrencyExceptionAsync(RelationalDataReader reader, Int32 commandIndex, Int32 expectedRowsAffected, Int32 rowsAffected, CancellationToken cancellationToken)
at Npgsql.EntityFrameworkCore.PostgreSQL.Update.Internal.NpgsqlModificationCommandBatch.Consume(RelationalDataReader reader, Boolean async, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Update.ReaderModificationCommandBatch.ExecuteAsync(IRelationalConnection connection, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Update.ReaderModificationCommandBatch.ExecuteAsync(IRelationalConnection connection, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Update.Internal.BatchExecutor.ExecuteAsync(IEnumerable`1 commandBatches, IRelationalConnection connection, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Storage.RelationalDatabase.SaveChangesAsync(IList`1 entries, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(IList`1 entriesToSave, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.ChangeTracking.Internal.StateManager.SaveChangesAsync(StateManager stateManager, Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
at Npgsql.EntityFrameworkCore.PostgreSQL.Storage.Internal.NpgsqlExecutionStrategy.ExecuteAsync[TState,TResult](TState state, Func`4 operation, Func`4 verifySucceeded, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.DbContext.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
at Volo.Abp.EntityFrameworkCore.AbpDbContext`1.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at Volo.Abp.EntityFrameworkCore.AbpDbContext`1.SaveChangesAsync(Boolean acceptAllChangesOnSuccess, CancellationToken cancellationToken)
at Volo.Abp.Uow.UnitOfWork.SaveChangesAsync(CancellationToken cancellationToken)
at Volo.Abp.Uow.UnitOfWork.CompleteAsync(CancellationToken cancellationToken)
at Volo.Abp.Uow.UnitOfWorkInterceptor.InterceptAsync(IAbpMethodInvocation invocation)
at Volo.Abp.Castle.DynamicProxy.CastleAsyncAbpInterceptorAdapter`1.InterceptAsync(IInvocation invocation, IInvocationProceedInfo proceedInfo, Func`3 proceed)
at Volo.Abp.Identity.IdentitySessionManager.RevokeAsync(IdentitySession session)
at Volo.Abp.Identity.IdentitySessionManager.RevokeAsync(String sessionId)
at Volo.Abp.Account.Web.Pages.Account.OpenIddictRevokeIdentitySessionOnRevocation.HandleAsync(HandleRevocationRequestContext context)
at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
at OpenIddict.Server.OpenIddictServerHandlers.Revocation.HandleRevocationRequest.HandleAsync(ProcessRequestContext context)
at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
at OpenIddict.Server.OpenIddictServerDispatcher.DispatchAsync[TContext](TContext context)
at OpenIddict.Server.AspNetCore.OpenIddictServerAspNetCoreHandler.HandleRequestAsync()
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Volo.Abp.AspNetCore.Security.AbpSecurityHeadersMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at Volo.Abp.Studio.Client.AspNetCore.AbpStudioMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
at Volo.Abp.Studio.Client.AspNetCore.AbpStudioMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
at Volo.Abp.Studio.Client.AspNetCore.AbpStudioMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at Volo.Abp.AspNetCore.Tracing.AbpCorrelationIdMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Localization.RequestLocalizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.RequestLocalization.AbpRequestLocalizationMiddleware.InvokeAsync(HttpContext context, RequestDelegate next)
at Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.InterfaceMiddlewareBinder.<>c__DisplayClass2_0.<<CreateMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)
Please fix this immediately. It does not happen in 8.
We are also experiencing the same issue.
We were prompted today to login to nuget.abp.io
We enter the credentials, and when trying to run the application we receive an error to login:
ABP-LIC-ERROR - License check failed for 'Volo.Payment.Domain-v5.1.3.0'.
You need to log in using the command abp login <username>.
When we try to login with abp login: ABP CLI 9.0.0
We have multiple abp commercial products with varying versions, all experiencing the same problem.
For what it's worth, I dug through ABP source code to find the culprit. It is on the PublishEntityCreatedEvent that gets called for every tracked entity in the AbpDbContext class. That eventually calls the AddOrReplaceEvent on the UnitOfWork class which does this: eventRecords.FindIndex(replacementSelector); where replacementSelector is defined as otherRecord => IsSameEntityEventRecord(eventRecord, otherRecord) in the EntityChangeEventHelper. That eventually gets to EntityHelper's EntityEquals(IEntity? entity1, IEntity? entity2) which uses a ton of reflection.
So for every new entity being tracked, it runs that equality reflection code for however many records have been inserted so far - the new tracked entity will never be in there, because it is new. So if I insert 200k entities, on the next entity added it runs through 200k entities to see if it needs to replace or add. The next entity after that it needs to do it 200,001 times. It gets exponentially slower, and it's very prohibitive. For what it's worth, I ended up fixing it by overriding the AbpDbContext and NOT publishing that tracked event for those entity types (ConnectWiseEntity is a base class I have for all 10 types) like so:
After that change, my bulk insert code went from 30-40 min to only 15 seconds.
I'd like to see 2 solutions here: make the local event publishing configurable like the distributed event publishing, AND fix the performance issue.
This is the code that does it in the EntityChangeEventHelper:
It runs the local event no matter what. Make that configurable like the distributed events below it.
I just made a brand new ABP project via the CLI on angular 18 and ABP 8.3.0, and it has the same issue.
Had to run yarn cache clean instead
The above steps did not work unfortunately, we're still left with the same warnings
Seems like the errors are coming from leptonx theme related components. SubNavbarComponent specifically? In the stacktrace/minified code, it points here: volo-ngx-lepton-x.core.mjs
function SubNavbarComponent_ng_template_2_Conditional_6_Template(rf, ctx) {
if (rf & 1) {
i0.ɵɵelementStart(0, "ul", 11);
i0.ɵɵrepeaterCreate(1, SubNavbarComponent_ng_template_2_Conditional_6_For_2_Template, 1, 1, "li", 12, _forTrack0, true);
i0.ɵɵelementEnd();
}
if (rf & 2) {
const ctx_r0 = i0.ɵɵnextContext(2);
i0.ɵɵclassProp("collapsed", !ctx_r0.item.expanded);
i0.ɵɵadvance();
i0.ɵɵrepeater(ctx_r0.item.children);
}
}
Here is our full package.json:
"name": "BMK",
"version": "0.0.0",
"scripts": {
"ng": "ng",
"start": "ng serve --open",
"build": "ng build",
"build:prod": "ng build --configuration production",
"watch": "ng build --watch --configuration development",
"test": "ng test",
"lint": "ng lint",
"generate-proxy": "bash ./generateProxy.sh",
"reset": "bash ./reset.sh"
},
"private": true,
"dependencies": {
"@abp/ng.components": "~8.3.1",
"@abp/ng.core": "~8.3.1",
"@abp/ng.oauth": "~8.3.1",
"@abp/ng.setting-management": "~8.3.1",
"@abp/ng.theme.shared": "~8.3.1",
"@angular/animations": "~18.2.6",
"@angular/common": "~18.2.6",
"@angular/compiler": "~18.2.6",
"@angular/core": "~18.2.6",
"@angular/forms": "~18.2.6",
"@angular/localize": "~18.2.6",
"@angular/platform-browser": "~18.2.6",
"@angular/platform-browser-dynamic": "~18.2.6",
"@angular/router": "~18.2.6",
"@volo/abp.commercial.ng.ui": "~8.3.1",
"@volo/abp.ng.account": "~8.3.1",
"@volo/abp.ng.audit-logging": "~8.3.1",
"@volo/abp.ng.gdpr": "~8.3.1",
"@volo/abp.ng.identity": "~8.3.1",
"@volo/abp.ng.language-management": "~8.3.1",
"@volo/abp.ng.openiddictpro": "~8.3.1",
"@volo/abp.ng.text-template-management": "~8.3.1",
"@volosoft/abp.ng.theme.lepton-x": "~3.3.1",
"primeflex": "^3.3.1",
"primeicons": "^7.0.0",
"primeng": "16.3.1",
"rxjs": "~7.8.0",
"tslib": "^2.0.0",
"zone.js": "~0.14.0"
},
"devDependencies": {
"@abp/ng.schematics": "~8.3.1",
"@angular-devkit/build-angular": "~18.2.6",
"@angular-devkit/core": "~18.2.6",
"@angular-devkit/schematics": "~18.2.6",
"@angular-eslint/builder": "~18.3.1",
"@angular-eslint/eslint-plugin": "~18.3.1",
"@angular-eslint/eslint-plugin-template": "~18.3.1",
"@angular-eslint/schematics": "~18.3.1",
"@angular-eslint/template-parser": "~18.3.1",
"@angular/cli": "~18.2.6",
"@angular/compiler-cli": "~18.2.6",
"@angular/language-service": "~18.2.6",
"@types/jasmine": "~3.6.0",
"@types/node": "^20.0.0",
"@typescript-eslint/eslint-plugin": "8.7.0",
"@typescript-eslint/parser": "8.7.0",
"@typescript-eslint/utils": "8.7.0",
"eslint": "^8.0.0",
"jasmine-core": "~4.0.0",
"karma": "~6.3.0",
"karma-chrome-launcher": "~3.1.0",
"karma-coverage": "~2.1.0",
"karma-jasmine": "~4.0.0",
"karma-jasmine-html-reporter": "^1.0.0",
"typescript": "~5.5.0"
}
}
We found it was because the email send type was changed to Queued, but we had disabled background jobs in our auth server. We had to manually add the line of code context.Services.Replace(ServiceDescriptor.Singleton<IBackgroundJobManager, NullBackgroundJobManager>()); even though the options had background jobs as disabled via Configure<AbpBackgroundJobOptions>(options => { options.IsJobExecutionEnabled = false; });. Feels like it should take that into account, instead of the literal implementation type of IBackgroundJobManager.
None that are different from the ABP 7 version, no. I got logs of both ABP 7 and ABP 8. 7 works, 8 doesn't - no obvious differences in the logs, no warnings/errors etc. nothing around that code has changed, the method still gets called with the same data.
We recently upgrade to ABP 8.0.0 and we're having errors of the Auth Server sending an email confirmation to a new user's email address. It does not send at all.
We use the SendEmailConfirmationTokenAsync() method from the AccountAppService to try to send this email to the user upon registering but the email never gets sent. When we downgrade to ABP 7 it will work though. We can't seem to find any documentation regarding our problem.