Backoffice Users without access to "Settings" can't create new Members

We’re experiencing an issue with Umbraco 8.6 and creating new members in the Backoffice UI. This only effects users that don’t have access to the “Settings”-section and it also seems like the “debug=true/false”-setting in web.config has a role in this.

Umbraco version:

I am seeing this issue on Umbraco version: 8.6.0

Reproduction

Make sure that web.config has “debug=false” set so that JS-files are bundled and minified in the backoffice.

Create a new User that has access to the “Members”-section but does not have access to the “Settings”-section and login as this User.

Go to the members-section and “Create a member”, fill out required fields and click save.

After this I’m given this error:

It’s really strange but if I switch back to “debug=true” in web.config this works. I’ve made sure to bump the ClientDependencyVersion number so it’s not a cache-issue with the client files.

Bug summary

As far as I can tell, the “contentTypeAlias” is returned from the “GetEmpty” call to the server when the “Create new Member”-page is loaded:

But when the payload is sent to the server to be saved, the alias is no longer there:

The server side error creates the following log entry:

{"@t":"2020-04-23T11:45:26.7603557Z","@mt":"Unhandled controller exception occurred for request '{RequestUrl}'","@l":"Error","@x":"System.InvalidOperationException: No member type found with alias \r\n   at Umbraco.Web.Editors.Binders.MemberBinder.CreateNew(MemberSave model) in D:\\a\\1\\s\\src\\Umbraco.Web\\Editors\\Binders\\MemberBinder.cs:line 135\r\n   at Umbraco.Web.Editors.Binders.MemberBinder.BindModel(HttpActionContext actionContext, ModelBindingContext bindingContext) in D:\\a\\1\\s\\src\\Umbraco.Web\\Editors\\Binders\\MemberBinder.cs:line 59\r\n   at System.Web.Http.ModelBinding.ModelBinderParameterBinding.ExecuteBindingAsync(ModelMetadataProvider metadataProvider, HttpActionContext actionContext, CancellationToken cancellationToken)\r\n   at System.Web.Http.Controllers.HttpActionBinding.<ExecuteBindingAsyncCore>d__12.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__5.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__3.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Web.Http.Controllers.ExceptionFilterResult.<ExecuteAsync>d__6.MoveNext()","RequestUrl":"https://..../umbraco/backoffice/UmbracoApi/Member/PostSave","SourceContext":"Umbraco.Web.Editors.MemberController","ProcessId":12496,"ProcessName":"w3wp","ThreadId":65,"AppDomainId":20,"AppDomainAppId":"LMW3SVC76ROOT","MachineName":"OBVI-WEB","Log4NetLevel":"ERROR","HttpRequestNumber":16,"HttpRequestId":"fbf82615-4796-4e80-b882-f07270ca7d21","RequestData":"------WebKitFormBoundaryt0BjYAAZkFW5wK8D\r\nContent-Disposition: form-data; name=\"contentItem\"\r\n\r\n{\"id\":0,\"properties\":[{\"id\":0,\"alias\":\"umbracoMemberComments\",\"value\":\"\"},{\"id\":0,\"alias\":\"umbracoMemberFailedPasswordAttempts\",\"value\":\"\"},{\"id\":0,\"alias\":\"umbracoMemberApproved\",\"value\":\"1\"},{\"id\":0,\"alias\":\"umbracoMemberLockedOut\",\"value\":\"No\"},{\"id\":0,\"alias\":\"umbracoMemberLastLockoutDate\",\"value\":\"\"},{\"id\":0,\"alias\":\"umbracoMemberLastLogin\",\"value\":\"\"},{\"id\":0,\"alias\":\"umbracoMemberLastPasswordChangeDate\",\"value\":\"\"},{\"id\":0,\"alias\":\"umbracoMemberPasswordRetrievalAnswer\",\"value\":\"\"},{\"id\":0,\"alias\":\"umbracoMemberPasswordRetrievalQuestion\",\"value\":\"\"},{\"id\":0,\"alias\":\"rootNode\",\"value\":\"umb://document/9023c70aeb2149669f71a4b805a0f1ad\"}],\"name\":\"dsfsdf\",\"contentTypeAlias\":null,\"parentId\":-1,\"action\":\"saveNew\",\"key\":\"5358986b4e20448fa7424759a4e36245\",\"email\":\"...@...se\",\"username\":\"sdfsdf\",\"password\":{\"newPassword\":\"....",\"reset\":true,\"answer\":null},\"memberGroups\":[\"Företagskund\"],\"comments\":\"\",\"isApproved\":true,\"isLockedOut\":false}\r\n------WebKitFormBoundaryt0BjYAAZkFW5wK8D--\r\n"}

The server does not return the content-object expected so this is why we get the front end error from the “getAllProps” that is trying to iterate the tabs-property that is not present since an error was returned.

Possible workarounds at the moment:

• Run the site with debug=true
• Give the User access to the “Settings”-section

I’m a little bit surprised that the debug-flag has any impact on this but it actually seem to have, I’ve tested this by bumping the clientDependencyVersionNumber and also removing all files in /App_Data/Temp/ClientDependency/* so I can’t see that it’s related to a cache-issue. When the User have access to the “Settings”-section the debug-mode does not matter, then it works all the time.

[enkelmedia]

@nul800sebastiaan PR sent, its a simple fix that would be great to include in 8.7.0 =D

[nul800sebastiaan]

@enkelmedia I would say go for the PR with the least amount of work necessary. 😊