ICurrentPrincipalAccessor.ClaimsPrincipal is sometimes null

[mavado83]

Is there an existing issue for this?

• I have searched the existing issues

Description

although stated that the Principal cannot be null, it can happen...

Visual Studio tells me that I can safely remove the '?' but then I got an exception.

Maybe it goes wrong here? https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Security/Volo/Abp/Security/Claims/ThreadCurrentPrincipalAccessor.cs

This can return null in runtime as a fallback..

public interface ICurrentPrincipalAccessor
{
  ClaimsPrincipal Principal { get; }

  IDisposable Change(ClaimsPrincipal principal);
}

Reproduction Steps

No response

Expected behavior

No response

Actual behavior

No response

Regression?

No response

Known Workarounds

No response

Version

10.4

User Interface

Common (Default)

Database Provider

EF Core (Default)

Tiered or separate authentication server

None (Default)

Operation System

Windows (Default)

Other information

No response

[maliming]

The ? is needed here — ICurrentPrincipalAccessor.Principal really can be null despite the non-nullable type. Outside an HTTP request (background job, hosted service, app initialization, a detached Task.Run, a non-web app, etc.) there's no HttpContext, so it falls back to Thread.CurrentPrincipal, which nothing sets → null.

Where are you reading Principal? A background worker / hosted service / event handler / something else? And do you expect a logged-in user to be there, or is it running with no user at all?

That's the part I want to pin down: if it's a genuine "no user" context, the fix is to return an empty (anonymous) principal there instead of null — same as what HttpContext.User already does. But if you expect the current user and it's just missing, that's a different problem (the principal isn't flowing into that context), and returning anonymous would only hide it.

[mavado83]

In this case we made a small mistake, we build a module where custom application events can be created. Instead of using a Manager or Store for creating the messages we used the AppService, but the appservice has authorization. So in this case a message was created by an eventhandler were no user is available (using an inbox pattern where the backgroundservice is trying to deliver a message were also the creation application event was happening). So a workaround (for our own module) we check if a user is logged in, if not a system user is impersonated to create the application event. But in this case we got the Null value.

To make a long story short: This is a "No user" context

[maliming]

Thanks, that's exactly the case the fix targets. A background event handler with no user is a legit "no user" context, and Principal returning null there is the bug — the interface is declared non-nullable, so your impersonation check shouldn't have to null-guard it.

The fix makes the fallback return an empty (anonymous) principal — unauthenticated, no user id — instead of null, matching what HttpContext.User already does. Your "is a user logged in?" check still reads false and your system-user impersonation kicks in as before, just without the NRE.

PR: #25752