Bug 29595

Summary: missing Content-Type / HTTP 415 check for POST requests to /api/v1/patrons
Product: Koha Reporter: Hans <divinity76>
Component: REST APIAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact:
Severity: trivial    
Priority: P5 - low CC: jonathan.druart, tomascohen
Version: unspecified   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32637
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Hans 2021-11-29 19:43:52 UTC
if you send a POST request to /api/v1/patrons with the header
Content-Type: application/x-www-form-urlencoded

which is a default header for curl and libcurl with POST requests, by the way, then Koha will try to parse it as a JSON, which leads to questions like this https://stackoverflow.com/questions/68106741/post-koha-patrons-to-koha-lms-using-php-curl/70155185#70155185 and responses like this

```
{
    //Here is missing some code.
    "errors": [{
            "message": "Missing property.",
            "path": "/body/address"
        },
        {
            "message": "Missing property.",
            "path": "/body/category_id"
        },
        {
            "message": "Missing property.",
            "path": "/body/city"
        },
        {
            "message": "Missing property.",
            "path": "/body/library_id"
        },
        {
            "message": "Missing property.",
            "path": "/body/surname"
        }],
    "status": 400
}
```

while HTTP 400 is a pretty good response, the correct response for unsupported Content-Type is actually 

>HTTP/1.1 415 Unsupported Media Type

and the error message could be something like

{    "errors": [{
            "message": "request body must be application/json"
        }],
]
Comment 1 Tomás Cohen Arazi (tcohen) 2021-12-03 12:28:54 UTC
We rely on the Mojolicious::Plugin::OpenAPI library to validate requests based on our OpenAPI 2.0 spec.

I'll try to check if there's a way to avoid this fallback behavior in the spec, but I haven't found anything yet. So, we depend on the library to take care of this situation.
Comment 2 Jonathan Druart 2023-02-01 10:58:21 UTC
I am expecting this to be enough, but apparently the spec validation is not working here.

diff --git a/api/v1/swagger/paths/patrons.yaml b/api/v1/swagger/paths/patrons.yaml
index 1100a9fba96..493be03d507 100644
--- a/api/v1/swagger/paths/patrons.yaml
+++ b/api/v1/swagger/paths/patrons.yaml
@@ -6,6 +6,8 @@
     tags:
       - patrons
     summary: List patrons
+    consumes:
+      - application/json
     produces:
       - application/json
     parameters:
Comment 3 Jonathan Druart 2023-02-01 10:59:58 UTC
(tried with GET instead of POST, but that's the same)
Comment 4 Jonathan Druart 2023-02-01 11:06:53 UTC
Is this https://github.com/jhthorsen/mojolicious-plugin-openapi/issues/209 ?
Comment 5 Jonathan Druart 2023-02-01 11:08:13 UTC
(In reply to Jonathan Druart from comment #4)
> Is this https://github.com/jhthorsen/mojolicious-plugin-openapi/issues/209 ?

Well, almost... 

"""
Please ask on IRC or open an issue if you found a bug, as this issue if for v3. (Sorry, but I’m unsure what you try to point out in the last comment)
"""