I was able to fix the 400 error which was caused by the js fetch client not having the ABP specific header config set. However, I am still having the issues with the unsupported media types.
I turned on all the logs and these ones are related to this request.
'api/app/form-response/evaluate-duplicate-rules/{formId}' is valid for the request path '/api/app/form-response/evaluate-duplicate-rules/ab7a81e6-e56a-fa31-0f5f-3a1cf5ff5eae'
[09:35:55 DBG] Request matched endpoint 'TOG.SaaSeForms.FormResponses.FormResponseClientProxy.EvaluateDuplicateRulesAsync (TOG.HttpApi.Client)'
[09:35:55 DBG] Static files was skipped as the request already matched an endpoint.
[09:35:55 INF] The access_token is active.
[09:35:55 DBG] AuthenticationScheme: Cookies was successfully authenticated.
[09:35:55 INF] Executing endpoint 'TOG.SaaSeForms.FormResponses.FormResponseClientProxy.EvaluateDuplicateRulesAsync (TOG.HttpApi.Client)'
[09:35:55 INF] Route matched with {area = "app", action = "EvaluateDuplicateRules", controller = "FormResponse", page = ""}. Executing controller a
ction with signature System.Threading.Tasks.Task1[TOG.SaaSeForms.DeDuplication.DuplicateResponseResult] EvaluateDuplicateRulesAsync(TOG.SaaSeForms.FormResponseDto, System.Guid) on controller TOG.SaaSeForms.FormResponses.FormResponseClientProxy (TOG.HttpApi.Client).
[09:35:55 DBG] Execution plan of authorization filters (in the following order): ["Volo.Abp.AspNetCore.Mvc.AntiForgery.AbpAutoValidateAntiforgeryTokenAuthorizationFilter"]
[09:35:55 DBG] Execution plan of resource filters (in the following order): ["Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.SaveTempDataFilter"]
[09:35:55 DBG] Execution plan of action filters (in the following order): ["Microsoft.AspNetCore.Mvc.ModelBinding.UnsupportedContentTypeFilter (Ord
er: -3000)", "Volo.Abp.AspNetCore.Mvc.GlobalFeatures.GlobalFeatureActionFilter", "Volo.Abp.AspNetCore.Mvc.Auditing.AbpAuditActionFilter", "Volo.Abp
.AspNetCore.Mvc.Response.AbpNoContentActionFilter", "Volo.Abp.AspNetCore.Mvc.Features.AbpFeatureActionFilter", "Volo.Abp.AspNetCore.Mvc.Validation.AbpValidationActionFilter", "Volo.Abp.AspNetCore.Mvc.Uow.AbpUowActionFilter"]
[09:35:55 DBG] Execution plan of exception filters (in the following order): ["Volo.Abp.AspNetCore.Mvc.ExceptionHandling.AbpExceptionFilter"]
[09:35:55 DBG] Execution plan of result filters (in the following order): ["Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.SaveTempDataFilter"]
[09:35:55 WRN] The required antiforgery header value "RequestVerificationToken" is not present.
[09:35:55 INF] Authorization failed for the request at filter 'Volo.Abp.AspNetCore.Mvc.AntiForgery.AbpAutoValidateAntiforgeryTokenAuthorizationFilter'.
[09:35:55 INF] Executing StatusCodeResult, setting HTTP status code 400
[09:35:55 INF] Executed action TOG.SaaSeForms.FormResponses.FormResponseClientProxy.EvaluateDuplicateRulesAsync (TOG.HttpApi.Client) in 0.1729ms
[09:35:55 INF] Executed endpoint 'TOG.SaaSeForms.FormResponses.FormResponseClientProxy.EvaluateDuplicateRulesAsync (TOG.HttpApi.Client)'
[09:35:55 INF] Request finished HTTP/2 POST https://localhost:44346/api/app/form-response/evaluate-duplicate-rules/ab7a81e6-e56a-fa31-0f5f-3a1cf5ff5eae?api-version=1.0 - 400 0 null 4.8285ms
It says it's failing on a antiforgery token, but there are several requests run immediately before this that work. Inspecting the network requests, I see the antiforgery cookie and the x-xsrf-token header.
I've seen this happen on other POST requests
I am not able to call the API directly since the new WebApp model applies credentials in the Blazor server before forwarding to the API. Having to maintain custom http client calls is also not acceptable overhead.
I can see the requests being fired so the validation is not happening in the brower.
I am having this issue where requests that work when using Blazor Server rendering fail when the page is rendered in WebAssembly Mode.
There are two similar errors I'm encountering.
[DisableValidation], and it works normally when using InteractiveServer, but not InteractiveAuto. It seems to fail in the generated controller, before reaching the proxy. No breakpoints or logging from the proxies are happening, and the 400 response from the server has no text. Is there a way to disable this eager validation and wait until it hits the api?
2. The is an API call that uploads a file using a using file upload dto, which again works when using InteractiveServer, but not InteractiveAuto. The error returned is Unsupported Media Type. Is there a way t fix this or disable it?Adding that attribute to the generated proxies did fix the launch issue, but then the api endpoints became Not Found in WASM mode. Is there a workaround for this, or does this need to wait for the patch?
Uploaded new repro
I followed these steps on my real project instead of the stripped down one and it didn't work. The proxies generated, and I switched to the static proxies in the http client project and then my blazor project wouldn't even launch. It was giving me initialization errors: 'TOG.WorkOrders.WorkOrderAttachmentTypeClientProxy.GetAttachmentTypeByIdAsync (TOG.HttpApi.Client)' has ApiExplorer enabled, but is using conventional routing. Only actions which use attribute routing support ApiExplorer.. See the inner exception for details.
Not sure if it's relevant, but that endpoint is inherited from a base attachment app service, so perhaps the routing model is different.
Is there a way to make this work with dynamic proxy generation? Is Blazor WebApp not compatible with the tiered model?
I have sent via wetransfer
I have emailed you a reproducible project. After running the migrator, you should be able to log in with the admin password System123!
After the site loads and login, the site will appear functional for some time, then with no user interaction go to an error screen and the console will be full of errors.
After completing all these steps, particularly changing the base url of the client project, I now get this error:
:44346 is the port of the Blazor WebApp.
