[bug] PUT /api/v1/akkoma/preferred_frontend might be broken #677

New Issue

Closed

opened 2024-01-31 22:56:20 +00:00 by Oneric · 2 comments

Oneric commented

2024-01-31 22:56:20 +00:00

Member

Your setup

From source

Extra details

Alpine 3.19

Version

6fb91d79f3 (at the time of writing: current develop)

PostgreSQL version

What were you trying to do?

Whatever I try, I’m unable to get anything but an error (due to non-matching function clause) when trying to use the PUT /api/v1/akkoma/prefered_frontened API endpoint. It seems like at the point it gets to calling available_frontends(conn, _params) the connection’s body parameters are always empty resulting in there never being a match.

The related GET /api/v1/akkoma/prefered_frontened/available works as expected and with only a minor modification to the request body and adding an authorisation header the PUT /api/v1/akkoma/frontend_settings/pleroma-fe/custom endpoint works as well.

I tried many variations of curl invocations and JS fetch API but none let me use the preferred_frontend API.

While somewhat embarrassing, ideally i’m just missing the obvious and everything is actually fine and I’d appreciate if someone could teach this sillyhead how to properly use this.
However, given the other PUT API works with basically the same request and the frontend endpoint was only reachable via /api/v1/akkoma/api/v1/akkoma/preferred_frontend until recently, it might also just be actually broken.

The Phoenix error page shown on unsuccessful requests indicates the empty body parameters, but at the same time reports the frontend_name = "pleroma-fe/stable" being passed in as a parameter at the bottom. As a wild guess, does maybe something strip out body parameters from unauthenticated (PUT) requests before it gets to the available_frontends(conn, _params) function?

Note this does not affect the related browser config site under /akkoma/frontend which can successfully set the cookie.

What did you expect to happen?

No response

What actually happened?

Working request for settings:

$ curl -i 'http://localhost:4000/api/v1/akkoma/frontend_settings/pleroma-fe/custom' -X PUT -H 'Authorization: Bearer XXX' -H 'Content-Type: application/json' --data-raw '{"version": 1, "settings":{"frontend_name": "pleroma-fe/stable"}}'

Output:

HTTP/1.1 200 OK access-control-allow-credentials: true access-control-allow-origin: * access-control-expose-headers: Link,X-RateLimit-Reset,X-RateLimit-Limit,X-RateLimit-Remaining,X-Request-Id,Idempotency-Key cache-control: max-age=0, private, must-revalidate content-length: 37 content-security-policy: style-src 'self' 'nonce-g8QHZX3sDjHJcDj';font-src 'self';script-src 'self' 'unsafe-eval' 'unsafe-inline';connect-src 'self' http://localhost:4000 ws://localhost:4000;media-src 'self' https:;img-src 'self' data: blob: https:;default-src 'none';base-uri 'none';frame-ancestors 'none';manifest-src 'self'; content-type: application/json; charset=utf-8 date: Wed, 31 Jan 2024 22:19:20 GMT permissions-policy: interest-cohort=() referrer-policy: same-origin server: Cowboy x-content-type-options: nosniff x-frame-options: DENY x-permitted-cross-domain-policies: none x-request-id: F6-OllzNkIbegrgAABSB x-xss-protection: 0 set-cookie: pleroma_key=SFMyNTY.g3QAAAABbQAAAAtvYXV0aF90b2tlbm0AAAAra0JXTlU0U2hkQkFHM1RxQ2hCUmFGcmJCSjNyT0FfNnE0YWtxZUxGQ1NEbw.XtibnVtQgCpXaXSi7kFwNfAQdxvgs7j-IO01FbL0Sqc; path=/; HttpOnly; SameSite=Lax

{"frontend_name":"pleroma-fe/stable"}

Failing preferred_frontend request:

$ curl -i 'http://localhost:4000/api/v1/akkoma/preferred_frontend' -X PUT -H 'Content-Type: application/json' --data-raw '{"frontend_name": "pleroma-fe/stable"}'

HTTP/1.1 400 Bad Request
access-control-allow-credentials: true
access-control-allow-origin: *
access-control-expose-headers: Link,X-RateLimit-Reset,X-RateLimit-Limit,X-RateLimit-Remaining,X-Request-Id,Idempotency-Key
cache-control: max-age=0, private, must-revalidate
content-length: 83110
content-type: text/html; charset=utf-8
date: Wed, 31 Jan 2024 22:17:10 GMT
permissions-policy: interest-cohort=()
referrer-policy: same-origin
server: Cowboy
x-content-type-options: nosniff
x-frame-options: DENY
x-permitted-cross-domain-policies: none
x-request-id: F6-OeBC4DtmsYkAAABPC
x-xss-protection: 0

Yielding this HTML error page (at least in dev env): tmp__bug_frontend.html

Logs

No response

Severity

I can manage

Have you searched for this issue?

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

### Your setup From source ### Extra details Alpine 3.19 ### Version 6fb91d79f37736ce1b3ac2ff1217f9a71bfcd44e (at the time of writing: current develop) ### PostgreSQL version 16 ### What were you trying to do? Whatever I try, I’m unable to get anything but an error (due to non-matching function clause) when trying to use the `PUT /api/v1/akkoma/prefered_frontened` API endpoint. It seems like at the point it gets to calling ` available_frontends(conn, _params)` the connection’s body parameters are always empty resulting in there never being a match. The related `GET /api/v1/akkoma/prefered_frontened/available` works as expected and with only a minor modification to the request body and adding an authorisation header the `PUT /api/v1/akkoma/frontend_settings/pleroma-fe/custom` endpoint works as well. I tried many variations of curl invocations and JS fetch API but none let me use the preferred_frontend API. While somewhat embarrassing, ideally i’m just missing the obvious and everything is actually fine and I’d appreciate if someone could teach this sillyhead how to properly use this. However, given the other PUT API works with basically the same request and the frontend endpoint was only reachable via `/api/v1/akkoma/api/v1/akkoma/preferred_frontend` until recently, it might also just be actually broken. The Phoenix error page shown on unsuccessful requests indicates the empty body parameters, but at the same time reports the `frontend_name = "pleroma-fe/stable"` being passed in as a parameter at the bottom. As a wild guess, does maybe something strip out body parameters from unauthenticated (PUT) requests before it gets to the `available_frontends(conn, _params)` function? Note this does not affect the related browser config site under `/akkoma/frontend` which can successfully set the cookie. ### What did you expect to happen? _No response_ ### What actually happened? Working request for settings: ``` $ curl -i 'http://localhost:4000/api/v1/akkoma/frontend_settings/pleroma-fe/custom' -X PUT -H 'Authorization: Bearer XXX' -H 'Content-Type: application/json' --data-raw '{"version": 1, "settings":{"frontend_name": "pleroma-fe/stable"}}' ``` <details> <summary>Output:</summary> <pre class="code-block"><code> HTTP/1.1 200 OK access-control-allow-credentials: true access-control-allow-origin: * access-control-expose-headers: Link,X-RateLimit-Reset,X-RateLimit-Limit,X-RateLimit-Remaining,X-Request-Id,Idempotency-Key cache-control: max-age=0, private, must-revalidate content-length: 37 content-security-policy: style-src 'self' 'nonce-g8QHZX3sDjHJcDj';font-src 'self';script-src 'self' 'unsafe-eval' 'unsafe-inline';connect-src 'self' http://localhost:4000 ws://localhost:4000;media-src 'self' https:;img-src 'self' data: blob: https:;default-src 'none';base-uri 'none';frame-ancestors 'none';manifest-src 'self'; content-type: application/json; charset=utf-8 date: Wed, 31 Jan 2024 22:19:20 GMT permissions-policy: interest-cohort=() referrer-policy: same-origin server: Cowboy x-content-type-options: nosniff x-frame-options: DENY x-permitted-cross-domain-policies: none x-request-id: F6-OllzNkIbegrgAABSB x-xss-protection: 0 set-cookie: pleroma_key=SFMyNTY.g3QAAAABbQAAAAtvYXV0aF90b2tlbm0AAAAra0JXTlU0U2hkQkFHM1RxQ2hCUmFGcmJCSjNyT0FfNnE0YWtxZUxGQ1NEbw.XtibnVtQgCpXaXSi7kFwNfAQdxvgs7j-IO01FbL0Sqc; path=/; HttpOnly; SameSite=Lax {"frontend_name":"pleroma-fe/stable"} </code></pre> </details> Failing preferred_frontend request: ``` $ curl -i 'http://localhost:4000/api/v1/akkoma/preferred_frontend' -X PUT -H 'Content-Type: application/json' --data-raw '{"frontend_name": "pleroma-fe/stable"}' HTTP/1.1 400 Bad Request access-control-allow-credentials: true access-control-allow-origin: * access-control-expose-headers: Link,X-RateLimit-Reset,X-RateLimit-Limit,X-RateLimit-Remaining,X-Request-Id,Idempotency-Key cache-control: max-age=0, private, must-revalidate content-length: 83110 content-type: text/html; charset=utf-8 date: Wed, 31 Jan 2024 22:17:10 GMT permissions-policy: interest-cohort=() referrer-policy: same-origin server: Cowboy x-content-type-options: nosniff x-frame-options: DENY x-permitted-cross-domain-policies: none x-request-id: F6-OeBC4DtmsYkAAABPC x-xss-protection: 0 ``` Yielding this HTML error page (at least in dev env): [tmp__bug_frontend.html](/attachments/597fd926-7a4b-4fd3-a7eb-1851dc1dbdf7) ### Logs _No response_ ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

tmp__bug_frontend.html

83 KiB

Oneric added the

bug

label 2024-01-31 22:56:20 +00:00

Oneric changed title from ~~[bug] PUT /api/v1/akkoma/prefered_frontened might be broken~~ to [bug] PUT /api/v1/akkoma/preferred_frontend might be broken

2024-01-31 22:57:03 +00:00

Oneric referenced this issue

2024-01-31 23:45:50 +00:00

Document Akkoma API #678

katafrakt referenced this issue

2024-02-03 13:36:01 +00:00

Fix OpenAPI spec for preferred_frontend endpoint #680

katafrakt commented

2024-02-03 13:48:21 +00:00

Contributor

This was a bit difficult to track down, but the reason was OpenAPI spec, which had operation id duplicated from another endpoint and indeed was scrubbing unknown parameters from the request.

👍 1

Oneric commented

2024-02-16 15:17:16 +00:00

Author

Member

Fixed by #680, thanks katafrakt!

Oneric closed this issue

2024-02-16 15:17:16 +00:00

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#677

No description provided.