[bug] /api/pleroma/notification_settings actually takes URI params instead of JSON body #722

New issue

Closed

opened 2024-03-18 08:37:45 +00:00 by Clovis · 1 comment

Clovis commented

2024-03-18 08:37:45 +00:00

Contributor

Your setup

OTP

Extra details

No response

Version

v3.10.4

PostgreSQL version

No response

What were you trying to do?

I'm trying to call the endpoint /api/pleroma/notification_settings documented here: https://docs.akkoma.dev/stable/development/API/pleroma_api/#apipleromanotification_settings

Since every calls in that page are taking a JSON body as input i'm sending a put request there with the following body:

{
    block_from_strangers: true
}

What did you expect to happen?

I get success as a response, but the setting is not actually changed.
The notification setting should be updated.

What actually happened?

However, after checking the tests in test/pleroma/web/twitter_api/util_controller_test.exs (line 30) I notice that this endpoint is actually taking URI params instead of a JSON body.

When I call /api/pleroma/notification_settings?block_from_strangers=true the setting is indeed changed as requested.

Logs

No response

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup OTP ### Extra details _No response_ ### Version v3.10.4 ### PostgreSQL version _No response_ ### What were you trying to do? I'm trying to call the endpoint `/api/pleroma/notification_settings` documented here: https://docs.akkoma.dev/stable/development/API/pleroma_api/#apipleromanotification_settings Since every calls in that page are taking a JSON body as input i'm sending a put request there with the following body: ``` { block_from_strangers: true } ``` ### What did you expect to happen? I get success as a response, but the setting is not actually changed. The notification setting should be updated. ### What actually happened? However, after checking the tests in test/pleroma/web/twitter_api/util_controller_test.exs (line 30) I notice that this endpoint is actually taking URI params instead of a JSON body. When I call `/api/pleroma/notification_settings?block_from_strangers=true` the setting is indeed changed as requested. ### Logs _No response_ ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

Clovis added the

bug

label 2024-03-18 08:37:45 +00:00

Oneric commented

2024-04-02 02:26:05 +00:00

Member

Thanks for reporting this

Since every calls in that page are taking a JSON body as input

Note, the page you linked already documents:

Request parameters can be passed via query strings or as form data. Files must be uploaded as multipart/form-data.

Coming from just the doc, the more surprising thing then is JSON bodies working at all ^^`
But yeah, almost all requests accept all three variants equally, URL parameters are usually discouraged and the doc should be updated

And /api/pleroma/notification_settings is still contradicting even this currently documented behaviour by solely accepting URL query parameters. The lack of support for form data parameter causes #691 since akkoma-fe performs this request with form parameters

I suspect the root cause here is this operations API spec explicitly listing the inputs under parameter: and an requestBody: nil isntead of using the same request_body() function as most other operations.

parameters: [

The request_body function builds something accepting any of "application/json", "multipart/form-data", "application/x-www-form-urlencoded"

def request_body(description, schema_ref, opts \\ []) do

Thanks for reporting this > Since every calls in that page are taking a JSON body as input Note, the page you linked already documents: > Request parameters can be passed via query strings or as form data. Files must be uploaded as multipart/form-data. Coming from just the doc, the more surprising thing then is JSON bodies working at all ^^` But yeah, almost all requests accept all three variants equally, URL parameters are usually discouraged and the doc should be updated And `/api/pleroma/notification_settings` is *still* contradicting even this currently documented behaviour by _solely_ accepting URL query parameters. The lack of support for form data parameter causes https://akkoma.dev/AkkomaGang/akkoma/issues/691 since akkoma-fe performs this request with form parameters I suspect the root cause here is this operations API spec explicitly listing the inputs under `parameter:` and an `requestBody: nil` isntead of using the same `request_body()` function as most other operations. https://akkoma.dev/AkkomaGang/akkoma/src/commit/2d439034ca801b704536cb05483e012d62c2d52e/lib/pleroma/web/api_spec/operations/twitter_util_operation.ex#L139 The `request_body` function builds something accepting any of `"application/json", "multipart/form-data", "application/x-www-form-urlencoded"` https://akkoma.dev/AkkomaGang/akkoma/src/commit/2d439034ca801b704536cb05483e012d62c2d52e/lib/pleroma/web/api_spec/helpers.ex#L10