Description
Debug mode
- I have enabled debug mode
- I have read checked the Common Issues page
Describe the bug
Issuing a POST to /api/v1/hardware/{id}/checkout with missing/incorrect parameters results in an inappropriate 302 redirect.
Due to a bug in the client-side code I'm working on, I inadvertently omitted the required checkout_to_type parameter from my request:
{"assigned_user": 1}The result was an unexpected 302 redirect.
HTTP/1.1 302 Found
...
Location: http://127.0.0.1:8888
Content-Type: text/html; charset=UTF-8
...
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<meta http-equiv="refresh" content="0;url='http://127.0.0.1:8888'" />
<title>Redirecting to http://127.0.0.1:8888</title>
</head>
<body>
Redirecting to <a href="http://127.0.0.1:8888">http://127.0.0.1:8888</a>.
</body>
</html>
This was particularly difficult to troubleshot because none of my logs in checkout() were being printed, before I realized that this was happening before the function was even dispatched, thanks to AssetCheckoutRequest.
Reproduction steps
- POST to
/api/v1/hardware/1/checkoutwith missing arguments.
Expected behavior
...anything more friendly than a redirect to somewhere completely unrelated!
A 400 or 422 with a JSON error would be nice.
This seems like a limitation of the Request base class, or just perhaps how Snipe-IT is using it in the API (not Web UI) case.
Screenshots
No response
Snipe-IT Version
v5.3.8
Operating System
Docker
Web Server
Apache (docker)
PHP Version
7.4 (docker)
Operating System
No response
Browser
No response
Version
No response
Device
No response
Operating System
No response
Browser
No response
Version
No response
Error messages
No response
Additional context
No response