Thanks, we are now in and that fix is almost the same as the fix I posted. We'll update the code to match this.
I think I tracked it down. The code creating the claims was dependent on a session tenant ID which does not exist at the time of login. but the user is retrieved from the db, that has that value. There is also another both where becuase this code is assuming a session tenant ID, if you log in as a super admin, then log out, then log in as a normal user you may end up with the wrong tenant id attached to your user identifier!
var userIdentifier = new UserIdentifier(AbpSession.TenantId, Convert.ToInt64(nameIdClaim.Value));
var userIdentifier = new UserIdentifier(user.TenantId??AbpSession.TenantId, Convert.ToInt64(nameIdClaim.Value));
Where can we see the fix. This is the same exact issue I reported a few months ago. The github links do not work.
https://support.aspnetzero.com/QA/Questions/8833/Multi-Tenant-Issues-after-build-agents-upgraded-to-31
I found a ticket reporting the same issue, but the links to github are no good. Can you share the fix?
https://support.aspnetzero.com/QA/Questions/8565
We cannot reproduce it locally and we have not customized the tenant code. Can't we analyze the version we are using? We are using version 7.0.0
So the issue is not resolved. It is still lingering and people are getting kicked out somewhat regularly. We see an error in the logs that looks like this:
These are multi-tenant users so that looks very wrong. It should look like this:
I've inspected the bearer tokens and they have the tenant in them. All the multi-tenant functionality seems to be working well besides this sporadic logout.
Thats fair but for right now any idea why in production we are seeing our users get kicked out throughout the day and seeing errors in the logs related where the Get user is called with a user ID and no tenant? The 2.2 version still was a production release that we paid for. We will try to upgrade soon but we need to get people not kicked out.
We are also running v7.0.
We are confident now that the downgrade of the SDK on the build agent resolved the issue. What is the path forward with this?
I've forced the azure pipeline to use the 2.2 SDK and rebuilt the same exact code and so far the issue seems resolved, but this isn't ideal long term.