Reproduction steps:
public class TestFeatureDefinitionProvider : FeatureDefinitionProvider
{
public override void Define(IFeatureDefinitionContext context)
{
var myGroup = context.AddGroup("Test Features");
var feature = myGroup.AddFeature(
name: "Test feature 1",
defaultValue: "true",
displayName: new FixedLocalizableString("Test feature 1"),
description: null,
valueType: new ToggleStringValueType()
);
var feature2 = feature.CreateChild(
name: "Test feature 2",
defaultValue: "true",
displayName: new FixedLocalizableString("Test feature 2"),
description: null,
valueType: new ToggleStringValueType()
);
var feature3 = myGroup.AddFeature(
name: "Test feature 3",
defaultValue: "true",
displayName: new FixedLocalizableString("Test feature 3"),
description: null,
valueType: new ToggleStringValueType()
);
}
}
Important part here is a null description. 3. Ran the application. 4. Logged in, confirmed the feature management modal worked. 5. Stopped the application. 6. Set FeatureManagementOptions.IsDynamicFeatureStoreEnabled to true in ConfigureService of web module. Commented out FeatureDefinitionProvider I had added (to simulate a feature seeded by another application). 7. Ran the application. 8. Logged in, went to feature management (for host, tenant, and edition) and modal fails to load with an error dialog.
Error in logs:
2025-03-27 17:53:21.044 +00:00 [ERR] Value cannot be null. (Parameter 'name')
System.ArgumentNullException: Value cannot be null. (Parameter 'name')
at System.ArgumentNullException.Throw(String paramName)
at Microsoft.Extensions.Localization.LocalizedString..ctor(String name, String value, Boolean resourceNotFound, String searchedLocation)
at Microsoft.Extensions.Localization.LocalizedString..ctor(String name, String value)
at Volo.Abp.Localization.FixedLocalizableString.Localize(IStringLocalizerFactory stringLocalizerFactory)
at Volo.Abp.FeatureManagement.FeatureAppService.CreateFeatureDto(FeatureNameValueWithGrantedProvider featureNameValueWithGrantedProvider, FeatureDefinition featureDefinition)
at Volo.Abp.FeatureManagement.FeatureAppService.GetAsync(String providerName, String providerKey)
at Castle.DynamicProxy.AsyncInterceptorBase.ProceedAsynchronous[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo)
at Volo.Abp.Castle.DynamicProxy.CastleAbpMethodInvocationAdapterWithReturnValue`1.ProceedAsync()
at Volo.Abp.Authorization.AuthorizationInterceptor.InterceptAsync(IAbpMethodInvocation invocation)
at Volo.Abp.Castle.DynamicProxy.CastleAsyncAbpInterceptorAdapter`1.InterceptAsync[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo, Func`3 proceed)
at Castle.DynamicProxy.AsyncInterceptorBase.ProceedAsynchronous[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo)
at Volo.Abp.Castle.DynamicProxy.CastleAbpMethodInvocationAdapterWithReturnValue`1.ProceedAsync()
at Volo.Abp.GlobalFeatures.GlobalFeatureInterceptor.InterceptAsync(IAbpMethodInvocation invocation)
at Volo.Abp.Castle.DynamicProxy.CastleAsyncAbpInterceptorAdapter`1.InterceptAsync[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo, Func`3 proceed)
at Castle.DynamicProxy.AsyncInterceptorBase.ProceedAsynchronous[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo)
at Volo.Abp.Castle.DynamicProxy.CastleAbpMethodInvocationAdapterWithReturnValue`1.ProceedAsync()
at Volo.Abp.Auditing.AuditingInterceptor.ProceedByLoggingAsync(IAbpMethodInvocation invocation, AbpAuditingOptions options, IAuditingHelper auditingHelper, IAuditLogScope auditLogScope)
at Volo.Abp.Auditing.AuditingInterceptor.InterceptAsync(IAbpMethodInvocation invocation)
at Volo.Abp.Castle.DynamicProxy.CastleAsyncAbpInterceptorAdapter`1.InterceptAsync[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo, Func`3 proceed)
at Castle.DynamicProxy.AsyncInterceptorBase.ProceedAsynchronous[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo)
at Volo.Abp.Castle.DynamicProxy.CastleAbpMethodInvocationAdapterWithReturnValue`1.ProceedAsync()
at Volo.Abp.Validation.ValidationInterceptor.InterceptAsync(IAbpMethodInvocation invocation)
at Volo.Abp.Castle.DynamicProxy.CastleAsyncAbpInterceptorAdapter`1.InterceptAsync[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo, Func`3 proceed)
at Castle.DynamicProxy.AsyncInterceptorBase.ProceedAsynchronous[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo)
at Volo.Abp.Castle.DynamicProxy.CastleAbpMethodInvocationAdapterWithReturnValue`1.ProceedAsync()
at Volo.Abp.Uow.UnitOfWorkInterceptor.InterceptAsync(IAbpMethodInvocation invocation)
at Volo.Abp.Castle.DynamicProxy.CastleAsyncAbpInterceptorAdapter`1.InterceptAsync[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo, Func`3 proceed)
at Volo.Abp.FeatureManagement.Web.Pages.FeatureManagement.FeatureManagementModal.OnGetAsync()
at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.ExecutorFactory.GenericTaskHandlerMethod.Convert[T](Object taskAsObject)
at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.ExecutorFactory.GenericTaskHandlerMethod.Execute(Object receiver, Object[] arguments)
at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.InvokeHandlerMethodAsync()
at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker.InvokeNextPageFilterAsync()
I will email you my solution as well, but above is all I did.
My issue was specific to features that came from the dynamic store, so it can't be in the static store (i.e. no FeatureDefinitionProvider containing the feature in the application that is displaying the features).
I was also viewing the features for a tenant, I didn't verify the behaviour was the same from any of the other feature management screens, but from what I've seen there's nothing to suggest this would make a difference.
If your feature wasn't available statically, and so is definitely coming from the dynamic store, then I can try and make the time and create a minimally reproducible sample if you would like; but if this would not be a priority regardless of reproducibility then feel free to just re-close this, since the workaround for what I am observing is to just add a description this is what I have done and therefore it's no longer a very pressing issue.
Created a Feature (using FeatureDefinitionProvider) without specifying a description.
With DynamicFeatureDefinitionStore the FeatureDefinition's Description has a FixedLocalizableString with a null value, whereas FeatureDefinition from static feature store has a null Description.
Then in FeatureAppService.GetAsync (in CreateFeatureDto method) the FeatureDefinition from DynamicFeatureDefinitionStore throws an exception when calling the Localize method for Description.
Thank you.
Since this is creating a lot of noise for us I am intending to make the following change in the mean time to prevent the error log.
Could you please confirm whether or not you believe this is appropriate, or suggest an alternative if not.
public class OpenIddictCreateIdentitySessionExceptForClientCredentials :
OpenIddictCreateIdentitySession,
IOpenIddictServerHandler<OpenIddictServerEvents.ProcessSignInContext>
{
private static readonly OpenIddictServerHandlerDescriptor _descriptor = OpenIddictServerHandlerDescriptor
.CreateBuilder<OpenIddictServerEvents.ProcessSignInContext>()
.UseSingletonHandler<OpenIddictCreateIdentitySessionExceptForClientCredentials>()
.SetOrder(100000)
.SetType(OpenIddictServerHandlerType.Custom)
.Build();
public OpenIddictCreateIdentitySessionExceptForClientCredentials(
IdentitySessionManager identitySessionManager,
IWebClientInfoProvider webClientInfoProvider,
IOptions<AbpAccountOpenIddictOptions> options) : base(identitySessionManager, webClientInfoProvider, options)
{
}
public new static OpenIddictServerHandlerDescriptor Descriptor
{
get
{
return _descriptor;
}
}
public new ValueTask HandleAsync(OpenIddictServerEvents.ProcessSignInContext context)
{
if (context == null)
throw new ArgumentNullException("context");
if (context.Request.IsClientCredentialsGrantType())
return ValueTask.CompletedTask;
return base.HandleAsync(context);
}
}
public override void PreConfigureServices(ServiceConfigurationContext context)
{
PreConfigure<OpenIddictBuilder>(builder =>
{
builder.AddServer(options =>
{
options.RemoveEventHandler(OpenIddictCreateIdentitySession.Descriptor);
options.AddEventHandler(OpenIddictCreateIdentitySessionExceptForClientCredentials.Descriptor);
});
});
}
I would also appreciate it if you could provide us with a link to any relevant issue or pull request on this ticket so that we may follow the progress of this fix and remove this code once it is redundant.
Kind regards, Josh
Error is the same as https://abp.io/support/questions/7977/AuthServer-820-SessionId-is-null-error but the steps differ.
When logging in as a user, I can see that IdentitySessionClaimsPrincipalContributor is correctly setting the sessionId, and the error does not occur.
This error is occurring during integrations we have running as background jobs, it occurs when /connect/token is called with client credentials flow. I have been investigating the error by making the api call using Postman, examining the returned access token I there is no session id, but I'm not sure if there should.
In the course of trying to understand the error I added an IOpenIddictServerHandler<OpenIddictServerEvents.ProcessSignInContext> just before OpenIddictCreateIdentitySession (where I believe the error is occurring) to confirm that there is indeed no session id (there wasn't). I subsequently modified my handler to add in session id, not believing this to be the fix but to see what would happen; this caused an exception in OpenIddictCreateIdentitySession when it tries to get the user id, which makes sense as there isn't a user.
So I am assuming that either: there shouldn't be a session id but this handler shouldn't be being called for my client credentials, or that there should be a session id but something in the way I have configured the application is causing it to not be created. Looking at the functionality provided by the session management it doesn't seem relevant (at least with our usage) to client applications, in combination with the fact that it is trying to get the user id, I am assuming at the moment that there shouldn't be a session, but this is not my area of expertise.
I do not believe there is anything particularly special with how the application has been configured:
I am not currently worried that this is causing any problems in our application, based on the fact that the handler simply logs the error and then returns, and if it didn't then the following call to IdentitySessionManager.CreateAsync would cause an exception. But the error is causing a lot of noise. I could inherit and then replace the handler, and only call the base implementation when it is not the client causing thin question; this would reduce the noise but is patently not the correct approach.
Any help would be greatly appreciated. Thanks in advance.
This was initially observed by new users (who were set up with no phone number) going to "Personal info" tab of the "/Account/Manage" page, clicking "Verify" (on their email) and then clicking "Submit" (without having made any changes). The submit changes the user's phone number from NULL to an empty string which creates a "ChangePhoneNumber" security log and updates the security stamp, this results in the verification email that was just sent being immediately invalid.
I believe this is caused by how the form is submitted by serializing the form which results in the null phone number becoming an empty string.
I have resolved this with the following change:
[Dependency(ReplaceServices = true)]
public class CustomProfileAppService : ProfileAppService
{
// Constructor omitted for brevity
public override async Task<ProfileDto> UpdateAsync(UpdateProfileDto input)
{
if (string.IsNullOrEmpty(input.PhoneNumber))
{
var user = await UserManager.GetByIdAsync(CurrentUser.GetId());
if (string.IsNullOrEmpty(user.PhoneNumber))
{
input.PhoneNumber = user.PhoneNumber;
}
}
return await base.UpdateAsync(input);
}
}
We are immediately providing user training to ensure this does not occur whilst we release this change as this has been reported multiple times, however, whilst what they are doing is unnecessary, I do not think it is unreasonable that they would not expect the steps they are taking to invalidate their verification token.
I have noticed that on submitting the "/Identity/Users/EditModal" the security stamp is changed every time. Which leads me to believe that it is being updated unnecessarily beyond the scenario that ours users have encountered.
Additionally it would be nice to have some visibility of when and why the security stamp changes in the security logs. The ChangePhoneNumber log is already present, and was key to us being able to diagnose what had happened here, but other changes (such as roles/permissions) which I believe to be valid reasons for the security stamp to change are not present in the security logs. It would also be nice to have a security log for when the security stamp has changed (even if this were always inferable from the other logs).
Thank you very much
When the "Allow users to change their email addresses" Identity Management setting is disabled users are not able to verify their email in the "Personal info" tab of the "Account" page.
Our site is quite tightly controlled and users are created by an administrator and not able to change their email. There also doesn't appear to be a way for administrators to trigger this email on behalf of a user that I can see.
I am aware that if we require emails to be verified then they would be able to verify it on login but at present we do not want this.
Is there any way to configure this so that the user is able to verify their email but not change it?
Currently I am working around the issue using the following javascript (any comments, criticisms or suggestions would be appreciated):
$(function () {
const $email = $('#PersonalSettingsForm').find("#Email")
if ($email) {
if ($email.parent().find("#VerifyEmailButton").length == 0 && $email.attr("data-email-verified") === "False") {
$email[0].insertAdjacentHTML('afterend', `
<button id="VerifyEmailButton" style="" class="btn btn-warning" type="button" data-busy-text="Processing...">
<i class="me-1 fa fa-vcard"></i> Verify
</button>
`);
}
if ($email.parent().find("#EmailVerified").length == 0 && $email.attr("data-email-verified") === "True") {
$email[0].insertAdjacentHTML('afterend', `
<span class="input-group-text" id="EmailVerified" style="">
<i class="me-1 text-success fa fa-check-square"></i><span class="text-success">Verified</span>
</span>
`);
}
}
});
Yes that did exactly what I wanted, Thank you very much for your help Anjali
We have recently upgraded to 7.3.2 as we are very excited to leverage the newly added ability to use authenticator apps for 2FA.
It all works great out the box, however we have observed that the default "Account Name" that appears in the authenticator app is taken from the web application name. We would like to be able to customise this per deployment as we have a separate web application that handles our authorization that is deployed for multiple clients. Unfortunately it is not feasible for us to do a build per deployment so we cannot do this by changing the assembly name. We have not been able to determine any way in which this can be configured but I am hoping that there is a way that we have missed?
If not is there a way to disable 2FA using authenticator apps whilst maintaining 2FA via email?
