Activities of "balessi75"

ABP Commercial 7.2.1 / Blazor Server / EF / Non tiered / Separate Host and Tenant DBs / Lepton Theme

Hi @liangshiwei,

I replicated the issue with a newly templated solution using the ABP CLI (see screenshot below) abp new ABP.Test -u blazor-server -v 7.2.1 -theme lepton

In local development with a simple ABP page, the problem almost can't be perceived because everything is running fast. The problem is magnified when a page has a lot to it. The problem is additionally magnified when being run from a hosted solution that is slower than in local development.

The problem seems to be isolated to the menu tree on the left where css styling applies after the content is loaded.

It's only an issue on the initial load of the application or on a browser level refresh. Navigating to different pages from the menu does not cause a problem.

Our application loads a significant dashboard once logged in and that's why the issue is more apparent to us, especially when running from a hosted solution on the internet.

I disabled caching in the browser's developer tools to be able to better see the problem for a screeenshot.

Any insight, suggestions, or workarounds would be greatly appreciated. Thanks.

Hi @liangshiwei,

We are on ABP 7.2.1 Blazor Server (Lepton) and this issue has been a big issue for us as well. We are not on LeptonX, rather we are using Lepton. Is there any attempt to correct this for the Lepton theme as well? I notice the above conversation only referring to the LeptonX theme.

Also, is there a temporary workaround for the Lepton theme?

As another ABP customers reported, this wasn't an issue in previous versions of ABP Blazor Server.

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.

I will try that and let you know what we find...

Hi,

Yes, this is strange.

We looked at logging and we can see that the http request for Account/ForgotPassword and Account/PasswordResetLinkSet is originating from the client, but the problem/unusual http request for Account/ResetPassword is originating from IP addresses in Microsoft's Data Centers (Azure platform running the ABP application).

Hi,

We do have multiple environments. We handle this with appsettings.json as follows:

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.

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 and ResetPassword

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 the Account/ResetPassword page with an invalid UserID and TenantID. The Account/ResetPasswordpage shouldn't be directed to until the user clicks the reset link in the email.

It looks like the steps that are happening is..

1. Click forgot email link and get directed to the Account/ForgotPassword page
2. Enter user email and click submit - get direct to the Account/PasswordResetLinkSet page
3. Email is successfully sent
4. 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.
5. 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

``

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.