Ends in:
7 DAYS
14 HRS
25 MIN
29 SEC
Ends in:
7 D
14 H
25 M
29 S

Activities of "jackmcelhinney"

Thanks, that resolved it. I had went ahead and upgraded to node v22 based on Angular 18's compatibility.

Hello,

I believe the issue is related to the subdomain tenant resolver, but I'm having trouble getting a local project running with subdomains so can't provide exact steps to reproduce. It seems the tenant is not set when OnGetAsync is called. Another solution to the issue is disabling the tenant filter on the verify token step:

public override async Task<IActionResult> OnGetAsync()
{
    var localLoginResult = await CheckLocalLoginAsync();
    if (localLoginResult != null)
    {
        LocalLoginDisabled = true;
        return localLoginResult;
    }

    ValidateModel();
    using (_dataFilter.Disable<IMultiTenant>())
    {
        InvalidToken = !await AccountAppService.VerifyPasswordResetTokenAsync(
        new VerifyPasswordResetTokenInput
        {
            UserId = UserId,
            ResetToken = ResetToken
        }
        );
    }

    SetNormalizeReturnUrl();
    return Page();
}

Also, the VerifyPasswordResetTokenAsync and VerifyEmailConfirmationTokenAsync methods in AccountAppService are not marked as virtual so cannot be overridden.

Let me know if you have any ideas on how the tenant is not set on the OnGetAsync but is set when the reset password form is submitted.

Thanks @maliming that worked. This section of the docs may need to be updated to use Configure instead of PreConfigure:

https://docs.abp.io/en/abp/latest/Modules/OpenIddict#automatically-removing-orphaned-tokens-authorizations

Possibly related to this? https://github.com/abpframework/abp/issues/4272

I don't think this is related to user requests cancelling, because this happens consistently every few hours even in the test project running locally with no user interaction and the API idling.

I now believe there is an impact on users when this happens, as I was on our site and got a service unavailable error for a few seconds at the same time these errors were logged. The errors are always in SettingManagement so it seems like there's an issue in that module handling cancellation or cache refreshes.

Received. Thanks!

Still experiencing this issue after removing skipIssuerCheck: true. I've done some more testing and can now consistently cause the issue in my project:

  1. Updated lifetimes for testing:
    • AccessTokenLifetime: 300 (5 minutes)
    • SlidingRefreshTokenLifetime: 600 (10 minutes)
    • AbsoluteRefreshTokenLifetime: 900 (15 minutes)
  2. Login
  3. Close the tab
  4. After 15 minutes, navigate back to the site

Please also note we are using the subdomain tenant resolver. Let me know if you have any other suggestions. Thanks!

Thanks for the suggestion. I have removed the skipIssuerCheck: true. I'm still not sure what causes this error to happen so I'll watch it the next few days and will let you know if it happens again.

Our app is not currently public, but I've included the information below. Let me know if there's anything else that could be helpful.

IdentityTokenLifetime: 300
AccessTokenLifetime: 3600
AuthorizationCodeLifetime: 300
AbsoluteRefreshTokenLifetime: 608400
SlidingRefreshTokenLifetime: 304200

Here is our environment.ts in case that helps as well:

We're just visually hiding the concept of a UserName by setting UserName = EmailAddress. That way users are created and sign in using only their email address, with no option for a different username.

I ended up solving my issue by adding a hidden userName property with a default value.

export function removeUserNameContributor(
  propList: FormPropList<IdentityUserDto>
) {
  let previousUserNameProp = propList.get(propList.findIndex(p => p.value.name == 'userName')).value
  propList.dropByValue(
    'userName',
    (prop, text) => prop.name === text
  )
  propList.addHead({
    ...previousUserNameProp,
    visible: c => false,
    defaultValue: 'DEFAULTVALUE'
  } as FormProp<IdentityUserDto>);

  let emailPropIndex = propList.findIndex(p => p.value.name == 'email');
  propList.addHead(propList.get(emailPropIndex).value);
  propList.dropByIndex(emailPropIndex + 1);
}

Then in CreateAsync I ignore the default value in the username and only use the email to create the user.

var user = new Volo.Abp.Identity.IdentityUser(
    GuidGenerator.Create(),
    input.Email,
    input.Email,
    CurrentTenant.Id
);

Now the username for all users will be their email address.

Showing 1 to 10 of 30 entries
Made with ❤️ on ABP v9.1.0-preview. Updated on November 20, 2024, 13:06