Hi @ismcagdas!
Yes, this file is up to date!
I was wondering if it might be related to one of my other issues: [exception when impersonating tenant user #8611](https://support.aspnetzero.com/QA/Questions/8611/exception-when-impersonating-tenant-user). I used the #if DEBUG preprocessor directive to work around this issue in my debug environment and thought it might interfere somehow now - I then reverted my changes but it didn't solve the current problem.
Hi @maliming and thank you for answer!
I built up a separate test environment to test your suggestion and it turned out to work perfectly on the new test environment!
Here is a list of rows I had to remove from AppSettings table:
Since applying your suggestion to production enivronment I'm facing another problem I'm currently trying to solve - but this seems to be another story.
I consider the original problem I posted here to be solved! Thanks again, @maliming!
@ricavir
I don't think this is the solution to the problem ... It just replaces the real CancellationTokenProvider with the NullCancellationTokenProvider (which does nothing).
I think @maliming just wanted me to test something there.
What I did as a work around to silence the exceptions during debugging is the following:
#if DEBUG
try
{
AsyncHelper.RunSync(() => ValidateSecurityStampAsync(principal));
}
catch
{
// ignore
}
#else
AsyncHelper.RunSync(() => ValidateSecurityStampAsync(principal));
#endif
Have a look at this one (might be the same): [exception when impersonating tenant user #8611](https://support.aspnetzero.com/QA/Questions/8611)
Hi @ismcagdas and thank you for your answer!
Yes, I'm already working on an implementation - I was just wondering if people where using other solutions for taxation ... maybe PayPal or Stripe offer something that is easy to use!?
Anyway, closing this now!
@maliming thank you for this information about cancellation-tokens!
Still, I wonder why I see an exception in my dev environment (in Visual Studio IDE, not in Logs.txt) since 8.2.1 ...
Anyway, thank your very much for your time @maliming!
@maliming actually, the exception doesn't seem to affect the application anywhere but in my development environment - and there I can simply click continue. Nothing bad seems to happen.
I already have it in production but I can't tell if it occurs there as well, since I don't have logs working in production environment yet (IIS, self hosted). It seems the application just continues to work as well.
So, yes, you are right - it might not affect the application in any bad way. But, should I remove the suggested code or should I keep it (I guess, you just wanted me to test something, right)?
@maliming where do i have to place this code? PreInitialize() of which module?
EDIT:
I placed it at the end of PreInitialize() in core-module - the exception is gone!
But what does it mean? Is this the solution you suggest? Are there any other implications with this? Or will this work fine?
@maliming no, the request has not been canceled.
FYI: After login, I'm not routing to the dashboard that comes with ASPNETZERO but to a custom component (which is a default feature but also needs permission) - could this have something to do with the exception thrown?
The exception also occurs when selecting another user of a specific tenant for impersonation, e.g.: