EtchUK / Etch.OrchardCore.UserProfiles

Orchard Core module provided useful extensions to users (e.g. profiles, subscriptions).
MIT License
6 stars 2 forks source link

Latest package version occasionally throws exception when user name contains `@` symbol #24

Open porgabi opened 2 years ago

porgabi commented 2 years ago

This problem is in an OC 1.3.0 app with UserProfiles package version 1.0.0. Using the package's ProfilePart on a custom content type, editing an existing profile throws an exception when the associated user's user name contains the @ symbol instead of +.

The app itself handles users with @ in user names and the profiles created via the sign up form are saved this way. Keeping the @ symbol in user names/emails over + would be much preferable here. I am aware one of the OC updates changed user names to use the + symbol instead, however this can still be changed in a startup by configuring IdentityOptions. Issue is configuring this locally does not affect the profile editor's behavior and the exception persists.

image

After publishing (Username field is also no longer displayed): image

The following warnings/exceptions are produced by the process: Microsoft.AspNetCore.Identity.UserManager|WARN|User validation failed: DuplicateEmail.

OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator|ERROR|IContentPartDisplayDriver thrown from Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay by ArgumentNullException System.ArgumentNullException: Value cannot be null. (Parameter 'user')

Full stack trace from OC logs:

OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator|ERROR|IContentPartDisplayDriver thrown from Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay by ArgumentNullException System.ArgumentNullException: Value cannot be null. (Parameter 'user')
   at OrchardCore.Users.Services.UserStore.GetUserIdAsync(IUser user, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Identity.UserManager`1.GetUserIdAsync(TUser user)
   at Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay.UpdateAsync(ProfilePart part, IUpdateModel updater, UpdatePartEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentDisplay.ContentPartDisplayDriver`1.OrchardCore.ContentManagement.Display.ContentDisplay.IContentPartDisplayDriver.UpdateEditorAsync(ContentPart contentPart, ContentTypePartDefinition typePartDefinition, UpdateEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator.<>c.<<UpdateEditorAsync>b__9_0>d.MoveNext()
--- End of stack trace from previous location ---
   at OrchardCore.Modules.InvokeExtensions.InvokeAsync[TEvents,T1,T2,T3](IEnumerable`1 events, Func`5 dispatch, T1 arg1, T2 arg2, T3 arg3, ILogger logger)    at OrchardCore.Users.Services.UserStore.GetUserIdAsync(IUser user, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Identity.UserManager`1.GetUserIdAsync(TUser user)
   at Etch.OrchardCore.UserProfiles.Drivers.ProfilePartDisplay.UpdateAsync(ProfilePart part, IUpdateModel updater, UpdatePartEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentDisplay.ContentPartDisplayDriver`1.OrchardCore.ContentManagement.Display.ContentDisplay.IContentPartDisplayDriver.UpdateEditorAsync(ContentPart contentPart, ContentTypePartDefinition typePartDefinition, UpdateEditorContext context)
   at OrchardCore.ContentManagement.Display.ContentItemDisplayCoordinator.<>c.<<UpdateEditorAsync>b__9_0>d.MoveNext()
--- End of stack trace from previous location ---
   at OrchardCore.Modules.InvokeExtensions.InvokeAsync[TEvents,T1,T2,T3](IEnumerable`1 events, Func`5 dispatch, T1 arg1, T2 arg2, T3 arg3, ILogger logger)

If this is intended behavior, is there a workaround perhaps?

Piedone commented 1 year ago

@peterkeating would you be able to check this out?