Activities of "hra"

Hi @velu,

We are also recently considering this undertaking - I would be interested to see how you went about achieving this. Could you please also share your code with me at [email protected]

Thank you and regards,

Hi there,

There is alot of code, sharing is not easy. I could have a remote session with you however, and walk you through it. I think the issue comes from the fact that when the DevExpress report server generates the actual report, it's no longer executing within the http request that the initial controllers were created through. It's a horrible "background thread" approach that just seems to cause issues - unfortunately, its how the DevExpress report server is designed to work - and I don't see it changing any time soon.

When I dump the stack trace, it doesnt contain any frames from above the Controller - no ASP.net frames, no Castle Windsor, Abp or AspNetZero... so I think it's a newly spawned thread.

One thing I would like to try, is fully re-initializing the DI container for my controller. Can you provide me with example code on how to fully initialize the DI container?

i.e, how do I create the ServiceCollection and populate it with all the same convention registered services, logging, etc....

Thanks,

hi,

yes, that looks like the same issue I'm having. I also found those 2 actions (editing the user permissions, or recycling the application pool) were the only solutions.

Of course, neither are really acceptable for my production customers...

Is there some part of the authentication token/crypto that is generated on app-start? If so, it would explain why recycling the server breaks active session tokens - i.e, theyre not expired, but essentially become corrupted...

I can reproduce this issue consistently. I can share a screen recording with you (privately) if you wish.

Hi, I have tracked down the issue.

After restarting the application server, and clicking "return to my account", all caches are empty - and the RoleManager will repopulate the cache with the admin user role permissions (role 1). The Role Manager calls "PermissionManager.GetAllPermissions(true)", and you can see that AbpSession still contains all the information for the impersonated account - rather than the impersonator account.

This fails to return the permissions on the Host side, and hence, a much smaller permission set (50, instead of 70-something) - but you can clearly see that this permission set is assigned in the cache to cacheKey "1@0".

This is what "GetAllPermissions" should look like...

Because these corrupt permissions are then stored in the cache, this explains why the application must be reset, or permissions changed (to trigger repopulation of the cache).

I guess the real question is - why is AbpSession still returning "MultiTenancySide == Tenant" after returning back to the Host account?

Hi @imscagdas,

I have created a PR in AspNetBoilerplate which fixes the issue for me. Please review.

UserManager and PermissionManager appear to use different techniques to determine the active MultiTenancySide - by copying across the UserManager technique to PermissionManager, it appears to resolve the issue.

Thanks and regards,

https://github.com/aspnetboilerplate/aspnetboilerplate/pull/6116

Hi @payoff,

Thank you for your suggestion. This is exactly the kind of best-practice I was looking for.

Regards,

Hi @ismcagdas,

Thank you for your response.

I hear your point, however I would like to respectfully appeal that you reassess your position for the sake of the AspNetZero/Boilerplate platform. All things being equal, if both are strange behaviors, it would be far safer to err on the side of not leaking potentially sensitive data to unintended users/organisations.

At best, data could be moved from tenant to host, causing the effect I had, a customer noticing missing data. At worse, data could be moved to another tenant, causing leakage of potentially sensitive data outside of the organisation, exposing your customers to potential legal ramifications.

Should the user have intended the data to be moved to another tenant, this specific failure would be observed in feature testing - as it's an explicit feature rather than an edge case. We could mitigate this being overlooked by throwing an exception should the tenant change without the "block tenant changes guard/filter" being disabled - this would clearly highlight the violation in testing.

There is no impact on my organisation given I have caught this flaw and mitigated it, so I promote discussion on this topic for the benefit of my peers in this community. I feel this also reflects on AspNetZero's internal security strategy whether or not to err on the side of caution.

Thank you and best Regards,

@ismcagdas - I'm pretty sure this is contributing to our issue here: https://support.aspnetzero.com/QA/Questions/10620/Setting-up-Microsoft-Azure-AD-Login

Where did this end up?

Hi @ismcagdas,

I'm on version 10.0 of Core/Angular.

Whats the justification for using OpenID Conect vs Microsoft?

A supplement to @ismcagdas's workaround - he's also supplied some additional code - thanks:

protected virtual void FillClaimsFromJObject(ExternalAuthUserInfo userInfo, JObject payload) { var dict = new Dictionary<string, string>(); foreach (var item in payload) { dict.Add(item.Key,item.Value?.ToString()); } userInfo.Claims = dict; }

You can use the class MicrosoftAuthProviderApi in the TokenAuthController's (for angular project) ExternalAuthenticate method. Just check for (input.AuthProvider == "Microsoft") and if it is true, create a new instance of MicrosoftAuthProviderApi and get the user info from your custom class.

If you are using the MVC version of AspNet Zero, you can do it in AccountController.