chore(401-when-jwt-token-is-missing): Returns 401 when jwt is missing or not parsable #45
Conversation
The HTTP 422 Unprocessable Content client error response status code indicates that the server understood the content type of the request content, and the syntax of the request content was correct, but it was unable to process the contained instructions. so i would say the 400 is better for the not parsable token. The only thing bothering me is 400 for missing JWT, i prefer a 401 for this. |
|
We will go for 401 when no token, 403 when token expired. |
… not parsable as a jwt token
papey
force-pushed
the
400-when-jwt-token-is-missing
branch
from
30f520b to
f23862c
Compare
papey
force-pushed
the
400-when-jwt-token-is-missing
branch
from
f23862c to
b31ccff
Compare
papey
changed the title
| "JWT authentication error: #{error_code} - #{error_message}, path: '#{conn.request_path}'", | ||
| category: "security", | ||
| error_code: "jwt_authentication.#{error_code}", | ||
| authorization_header: conn |> get_req_header("authorization") |> List.first(), |
There was a problem hiding this comment.
@papey the authorization_header metadata is not automatically added to json logs. The header should be added directly to the error message, and maybe neurow/lib/neurow/ecs_log_formatter.ex should be updated to add the authorization header in the JSON payload (while ensuring it conforms to the ECS log format)
Context 🧐
This PR change the behavior when JWT is not present or not parsable as a JWT token, other error later in the chain, when you have a JWT in hand are not modified.
Changes ⛏️
Returns a 401 when the request does not contains a valid JWT token (valid: present & at least parsable)