Hello,
Following the update to ABP from version 9 to 10, we are receiving this message on a series of endpoints when the token has expired with the 400 code.
{ "error": { "code": null, "message": "ValidationErrorMessage", "details": "ValidationNarrativeErrorMessageTitle\r\n - The value 'Error' is not valid.\r\n", "data": {}, "validationErrors": [ { "message": "The value 'Error' is not valid.", "members": [ "id" ] } ] }
Previously, we received the code 401 "Unauthorised", which is the correct one.
Has any change been made that could be affecting this?
Thanks,
3 Answer(s)
-
0
Nothing in ABP v10 “intentionally” changes an expired/invalid access token response from 401 to 400.
The payload you posted is an ABP validation error (it’s coming from model binding/validation, not from authentication). The key clue is:
validationErrors→ member:"id"→"The value 'Error' is not valid."That means the request is reaching the action and ASP.NET Core is trying to bind a parameter/route value named
id(likelyGuid/int). Instead of a valid id, the literal string"Error"is being sent.
What’s most likely happening
When the token expires, your client is no longer calling the real endpoint URL, but a URL that contains
"Error"in the{id}segment (or it is sending"Error"as a query/body field namedid). Common causes after upgrades are:- an HTTP client / API proxy / interceptor that on 401 rewrites or retries the request incorrectly,
- a custom “refresh token” handler that, on failure, returns
"Error"and that value gets used as theidfor the next request, - Blazor client-side code that navigates to an error route and then reuses the current route parameter as
id.
So ABP returns 400 because the request is malformed (invalid
id), before/independently of auth.Fix (server-side + client-side)
Client-side: ensure you don’t build URLs with an error string
- Find the failing calls and log the final request URL when the token is expired.
- Verify the
{id}segment (oridparameter) is still a real Guid/int when you get the expired-token case.
Client-side: handle 401 properly
- When you receive 401, either:
- refresh the token and retry, or
- redirect to login,
- but do not continue calling business endpoints with placeholder/error strings for route values.
- When you receive 401, either:
Server-side verification
- Add logging (or inspect logs) to confirm the requested path when the issue occurs. You should see something like
/api/.../Error/...or?id=Error.
- Add logging (or inspect logs) to confirm the requested path when the issue occurs. You should see something like
If after confirming the actual requested URL you still see ABP returning 400 while the request URL and route params are correct, then it would be something different—but with the error payload you posted, it’s a request validation/model-binding problem, not an auth-status-code change.
- https://abp.io/docs/latest/framework/infrastructure/csrf-anti-forgery
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
I need more help
-
0
hi
Can you share more debug/error logs?
liming.ma@volosoft.com
Thanks.
