Note: Thread.CurrentPrincipal not flowing for async operations on Mono

[dazinator]

I discovered a problem with Mono recently, when running on Android, if you set Thread.CurrentPrincipal, and then perform some async operation (i.e Task.Run()) - the principal won't flow to the new thread. If the async operation happens to execute fully on the same thread, obviously you get away with it, but if it runs on a new thread, Thread.CurrentPrincipal is lost. I created an issue at mono repo and it looks like there may be a fix in progress - but thought I would mention it here in case this impacts CSLA authentication code on Android devices. Interestingly if you use Task.Factory.StartNew - with the LongRunning option, then it does flow.

The fact this hasn't worked for so long on Mono makes me think that Thread.CurrentPrincipal (and in fact Principal's in general) is simply not used at all by Xamarin Android developers..

[rockfordlhotka]

In most environments CSLA doesn't manage the current identity, allowing the underlying platform to handle the identity on our behalf.

The exceptions are WPF and Windows Forms, where the underlying platform doesn't handle the current identity in a way that makes any sense, so we maintain the current identity (from a CSLA perspective) in a static.

CSLA also adapts to running in ASP.NET and uses HttpContext instead of the current thread, because those don't always match in the web server scenario, and only HttpContext is reliable.

The Csla.Threading namespace (iirc) has a Task helper that helps flow context values to new threads. You might look at that - this issue is not unique to mono.

A workaround we could consider for Android, is to have a custom CSLA app context provider, like the ones for WPF/WinForms, that maintains the current identity in a static.

[dazinator]

The Csla.Threading namespace (iirc) has a Task helper that helps flow context values to new threads. You might look at that - this issue is not unique to mono.

I did not know that. Thank you, I will take a look.

A workaround we could consider for Android, is to have a custom CSLA app context provider, like the ones for WPF/WinForms, that maintains the current identity in a static.

Sounds good, an AsyncLocal I gather. I have not actually tested what CSLA application context on Android does. It may already handle this. I was kind of assuming CSLA may be relying on Thread.CurrentPrincipal and the platform to flow it - if thats the case then I expect it will be impacted by this issue. If it already has some custom context provider for android that uses static or asynclocal filed then that should be ok.

[dazinator]

This has now been fixed in the next release of mono: mono/mono#6326 (comment)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.