Our customer reported that at least one of the Forms used on their Opti 12CMS intranet can't be submitted sometimes, but we can't manage to find the reason for the error. It doesn't really seem to make any difference if the page containing the form was open for 5, 10,.., x minutes or if the page is reloaded, which makes us think that the problem isn't session related.
We don't think that the issue is related to a specific form because we have managed to get the error even for a newly created (really simple) form.
The error is really hard to reproduce (in the dev enviroment at least), but we are quite certain that it has to do with the failed ACL validation from from the EPiForms.Core library within the DataSubmissionService.PerformDataSubmitAsync() method. I have traced the error message that the customer gets in the client to the "formisrestricted" error, that is thrown when the user doesn't have Read accesslevel.
if (!(formContainer as IContentSecurable).GetContentSecurityDescriptor().HasAccess(httpContext.User, AccessLevel.Read))
{
_logger.Debug("Could not submit. Form is restricted. Form Guid = {0}, Id = {1}.", text, formContainer.Content?.ContentLink);
empty = LocalizationService.GetString("/episerver/forms/messages/formsubmission/formisrestricted");
return BuildReturnResultForSubmitAction(isJavaScriptSupport, isSuccess: false, empty, httpContext);
}
We have created a logging middleware which loggs the HttpContext.User object upon the request to the page and when the form subbmission wasn't succesful.
The User object seems to be the "default" User when we get a submission error, instead of having the name and other important Claims added.
The site uses a custom WindowsAuthenticationProvider, which works as supossed in the different areas of the site (even with forms), so we are quite sure that the problem isn't related to it.
On the other hand, we are starting to wonder if the intermitent fault can't be the result of the HttpContext isn't being thread safe. I've started logging event the ThreadId when logging the User object and I noticed that the ThreadId isn't the same when logging the User upon the request and if a fault occured.
We are realy wondering if anyone else has stumbled upon similar issues as this or other problems related to threading? I can't say with certainty that the logged information is relevant, since we are kind of lost when it comes to this problem. We would preferably like to log the User object right before the ACL is checked in the Forms.Core library, but that ain't posible.
We are using EPiServer CMS v12.22.5 and EPiServer.Forms v5.7.0 running on IIS 10.
Thank you in advance for any tips or ideeas :)
//Alex
Update (it may help):
The form isn't posting at all using Firefox (Developer edition 119.0b7 (64-bit)) neither on Windows or MacOS, returning the same client error message. The logged user object has the two diferent states, as described above and I also managed to see that the submit is erroneous even when the ThreadId (System.Threading.Thread.CurrentThread.ManagedThreadId) is the same both when logging the request and response.
Hi everyone,
Our customer reported that at least one of the Forms used on their Opti 12CMS intranet can't be submitted sometimes, but we can't manage to find the reason for the error. It doesn't really seem to make any difference if the page containing the form was open for 5, 10,.., x minutes or if the page is reloaded, which makes us think that the problem isn't session related.
We don't think that the issue is related to a specific form because we have managed to get the error even for a newly created (really simple) form.
The error is really hard to reproduce (in the dev enviroment at least), but we are quite certain that it has to do with the failed ACL validation from from the EPiForms.Core library within the DataSubmissionService.PerformDataSubmitAsync() method. I have traced the error message that the customer gets in the client to the "formisrestricted" error, that is thrown when the user doesn't have Read accesslevel.
We have created a logging middleware which loggs the HttpContext.User object upon the request to the page and when the form subbmission wasn't succesful.
The User object seems to be the "default" User when we get a submission error, instead of having the name and other important Claims added.
The site uses a custom WindowsAuthenticationProvider, which works as supossed in the different areas of the site (even with forms), so we are quite sure that the problem isn't related to it.
On the other hand, we are starting to wonder if the intermitent fault can't be the result of the HttpContext isn't being thread safe. I've started logging event the ThreadId when logging the User object and I noticed that the ThreadId isn't the same when logging the User upon the request and if a fault occured.
We are realy wondering if anyone else has stumbled upon similar issues as this or other problems related to threading? I can't say with certainty that the logged information is relevant, since we are kind of lost when it comes to this problem. We would preferably like to log the User object right before the ACL is checked in the Forms.Core library, but that ain't posible.
We are using EPiServer CMS v12.22.5 and EPiServer.Forms v5.7.0 running on IIS 10.
Thank you in advance for any tips or ideeas :)
//Alex
Update (it may help):
The form isn't posting at all using Firefox (Developer edition 119.0b7 (64-bit)) neither on Windows or MacOS, returning the same client error message. The logged user object has the two diferent states, as described above and I also managed to see that the submit is erroneous even when the ThreadId (System.Threading.Thread.CurrentThread.ManagedThreadId) is the same both when logging the request and response.