ABP Commercial 7.2.1 / Blazor Server / EF / Non tiered / Separate Host and Tenant DBs / Lepton Theme
Hi we are getting the below exception in the logs when we run in production. We don't seem to have the issue in local development, but are receiving the exception when we deploy the application to an Azure Appservice. The exception refers to an IdentityUser
with an id of f8f7d016-0050-a3aa-96a3-6b3cc9e3e1c2
not being found.
We confirmed that there is NO AbuUser record existing with this ID in either our tenant DB or host DB. We don't know where this ID is coming from or where to look from here.
Thanks in advance as we need a solution ASAP. Regards, Brian
19 Answer(s)
-
0
Hi,
I don't think this is a problem. For example, maybe the user's account has been deleted on the admin side when he tries to reset his password.
Usually, you can ignore it.
-
0
Hi,
I checked that, the user's email we are entering is not associated with a deleted account.
It's happening with any user email that we test with. For each user, a different ID is specified in the exception, but for all users the exception references an ID that doesn't exist anywhere in the database.
-
0
Hi,
I believe this is a misoperation or someone is trying to test(crack) your website.
BTW, If you can provide reproducible steps, I will check it.
-
0
Hi,
What's strange is that the exception is logged both when resetting a password (forgot password link) and also when confirming an email address (email confirmation link sent). In both situations the emails are delivered correctly to the end user even though the exception occurs in the error log.
We've seen ABP operate differently in Azure before https://support.abp.io/QA/Questions/5024/Invalid-Email-Confirmation-Token-Always-Occuring#answer-3a0b1aac-3ee4-e947-105d-f2f20f9ee31b and implemented workarounds with the help of ABP support.
I'll see if I can deploy an empty/newly templated base ABP app to Azure in order to replicate, which should eliminate the possibility that any of our logic/overrides are contributing to the issue.
The Azure logs show that there are no testers/attackers hitting the web application.
-
0
I'll see if I can deploy an empty/newly templated base ABP app to Azure in order to replicate, which should eliminate the possibility that any of our logic/overrides are contributing to the issue.
Ok,
-
0
Hi, Here is what I was able to find and I was wondering if you have any ideas...
We isolated the problem to a small change we recently made. We changed the APB setting value of the mail send from address (
Abp.Mailing.DefaultFromAddress
) to a new value. This single change caused the exception. When we revert the send from mail address to its original value, everything works as expected.After looking closer at the logs, it looks like for some reason, at the point you click 'Submit' on the
Account/ForgotPassword
page, the system attempts to direct to theAccount/ResetPassword
page with an invalid UserID and TenantID. TheAccount/ResetPassword
page shouldn't be directed to until the user clicks the reset link in the email.It looks like the steps that are happening is..
- Click forgot email link and get directed to the
Account/ForgotPassword
page - Enter user email and click submit - get direct to the
Account/PasswordResetLinkSet
page - Email is successfully sent
- Incorrectly does a GET to the
Account/ResetPassword
page with an invalid UserID and TenntID before the user clicks the link in the email and exception occurs. - User can then click the link in the email and they are successfully directed to the
Account/ResetPassword
page with the correct UserID and TenantID
``
- Click forgot email link and get directed to the
-
0
We isolated the problem to a small change we recently made. We changed the APB setting value of the mail send from address (Abp.Mailing.DefaultFromAddress) to a new value. This single change caused the exception. When we revert the send from mail address to its original value, everything works as expected.
You mean that after reverting the change, the
PasswordResetLinkSet
page will not be automatically redirected, right?I checked the source code, page does not contain automatic redirection code, have you customized the page?
BTW, could you provide a test email to me? I want to test it. thanks
-
0
You mean forward you an email password reset email from our test instance? Sure, I can do that.
This s only happens when running ABP in Azure. When we run from VS in our local development environment we don't see the issue.
We have no overrides/customizations to
PasswordResetLink
We use SendGrid as our email provider.
This is everything logged between
PasswordResetLinkSent
andResetPassword
-
0
-
0
-
0
Hi,
Apologies for the confusion. The reset link works fine, we were just concerned about the exceptions in the logs and if there was any concerns that we should be aware of.
Thanks.
-
0
-
0
Hi,
We do have multiple environments. We handle this with appsettings.json as follows:
-
0
Hi,
It's interesting.
Actually I have no idea about this.
You can consider logging when resetting the password to ensure that the reset password link is not sent by the application.
And record the Http request header information to check the client sending the request.
-
0
Hi,
Yes, this is strange.
We looked at logging and we can see that the http request for
Account/ForgotPassword
andAccount/PasswordResetLinkSet
is originating from the client, but the problem/unusual http request forAccount/ResetPassword
is originating from IP addresses in Microsoft's Data Centers (Azure platform running the ABP application). -
0
Hi,
I'll see if I can deploy an empty/newly templated base ABP app to Azure in order to replicate, which should eliminate the possibility that any of our logic/overrides are contributing to the issue.
Can the problem be reproduced in the new template?
-
0
I will try that and let you know what we find...
-
0
ok. thanks
-
0
Hi @liangshiwei,
We deployed a newly templated ABP app to an Azure Azure Appservice that only includes our Sendgrid implementation for sending emails and everything worked as expected.
After further research - under certain conditions, it appears that the Azure platform is performing scanning/prefetching of the password reset link in the email, causing the ABP exceptions.
We updated the SPF and DKIM settings for our sending domain and upgraded our Sendgrid account from a free plan to a paid plan.
After performing these actions everything seems to be working fine.
My thinking is that the free Sendgrid plan included something in the email headers that was triggering Azure to scan the emails and prefetch the email's link.
Hope this information helps someone else.