`api/v1/akkoma/preferred_frontend*`s have path prefix duplicated #604

New issue

Closed

opened 2023-07-25 16:03:26 +00:00 by Oneric · 1 comment

Oneric commented

2023-07-25 16:03:26 +00:00

Member

Your setup

From source

Extra details

(actually no own server atm but that wasn't an option to select; I was looking through the code since besides the prometheus endpoint no akkoma-specifc API is documented. I verified this behaviour on some public instances on 3.9.3. If it helps debugging in anyway I can try to spin up a local test instance.)

Version

tested servers on 3.9.3; code still seems affected as of git HEAD 33e7ae7637

PostgreSQL version

What were you trying to do?

Commit 3d964a9970 added REST API endpoints for listing and selecting the available/prefered frontend. However it accidentally duplicated the /api/v1/akkoma/ prefix in lib/pleroma/web/router.ex, so the API endpoints are now actually available under /api/v1/akkoma/api/v1/akkoma/preferred_frontend(/available) instead of /api/v1/akkoma/preferred_frontend(/available).

No other endpoint in router.ex duplicates the scope into the put/post/get part afaict.

A further note, while I’m able to use the PUT /api/v1/akkoma/api/v1/akkoma/preferred_frontend to select a frontend an the expected Set-Cookie header is snet in the response. I cannot get GET /api/v1/akkoma//api/v1/akkoma/preferred_frontend/available to list anything; see logs for what it returns instead.

Adding a frontend_name parameter to the request doesn't change the response. But perhaps I’m missing something obvious and the listing not working is my fault.

The web interface under akkoma/frontend (added two commits later in de64c6c54a) works as expected, including listing (a single) available frontend.

What did you expect to happen?

API endpoints being GET /api/v1/akkoma/preferred_frontend/available　and PUT /api/v1/akkoma/preferred_frontend and listing available frontends working without any additional parameters.

What actually happened?

see “What were you trying to do?”

Logs

$ curl -i -X GET -b "preferred_frontend=pleroma-fe/stable;" https://ihatebeinga.live/api/v1/akkoma/api/v1/akkoma/preferred_frontend/available

HTTP/2 400 
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
age: 0
alt-svc: h3=":443"; ma=2592000
cache-control: max-age=0, private, must-revalidate
content-security-policy: upgrade-insecure-requests;style-src 'self' 'nonce-sQdsIMmNgbZMxkT';font-src 'self';script-src 'self' 'nonce-sQdsIMmNgbZMxkT' ;connect-src 'self' https://ihatebeinga.live wss://ihatebeinga.live  https://media.ihatebeinga.live https://media.ihatebeinga.live https://captcha.ihatebeinga.live;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: Tue, 25 Jul 2023 15:51:38 GMT
permissions-policy: interest-cohort=()
referrer-policy: same-origin
server: Caddy
server: Cowboy
via: 1.1 ihatebeinga.live (Varnish/7.2)
x-content-type-options: nosniff
x-frame-options: DENY
x-permitted-cross-domain-policies: none
x-request-id: F3UnKpGkKHNt31IAJ6Ri
x-varnish: 16482848
x-xss-protection: 0
content-length: 157

{"error":"Missing field: frontend_name.","errors":[{"message":"Missing field: frontend_name","source":{"pointer":"/frontend_name"},"title":"Invalid value"}]}

Severity

I can manage (just wanted to let you know since this doesn't seem intentional)

Have you searched for this issue?

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

### Your setup From source ### Extra details (actually no own server atm but that wasn't an option to select; I was looking through the code since besides the prometheus endpoint no akkoma-specifc API is documented. I verified this behaviour on some public instances on 3.9.3. If it helps debugging in anyway I can try to spin up a local test instance.) ### Version tested servers on 3.9.3; code still seems affected as of git HEAD 33e7ae7637236b859bfabc9016a86e4bbe1e0632 ### PostgreSQL version - ### What were you trying to do? Commit 3d964a997033ea65e97cbd08b6549f9cdf445fc9 added REST API endpoints for listing and selecting the available/prefered frontend. However it accidentally duplicated the `/api/v1/akkoma/` prefix in `lib/pleroma/web/router.ex`, so the API endpoints are now actually available under `/api/v1/akkoma/api/v1/akkoma/preferred_frontend(/available)` instead of `/api/v1/akkoma/preferred_frontend(/available)`. No other endpoint in `router.ex` duplicates the scope into the `put`/`post`/`get` part afaict. A further note, while I’m able to use the `PUT /api/v1/akkoma/api/v1/akkoma/preferred_frontend` to select a frontend an the expected `Set-Cookie` header is snet in the response. I cannot get `GET /api/v1/akkoma//api/v1/akkoma/preferred_frontend/available` to list anything; see logs for what it returns instead. Adding a `frontend_name` parameter to the request doesn't change the response. But perhaps I’m missing something obvious and the listing not working is my fault. The web interface under `akkoma/frontend` (added two commits later in de64c6c54aaacc4123031f2e3d5bfb9fc9c517fe) works as expected, including listing (a single) available frontend. ### What did you expect to happen? API endpoints being `GET /api/v1/akkoma/preferred_frontend/available`　and `PUT /api/v1/akkoma/preferred_frontend` and listing available frontends working without any additional parameters. ### What actually happened? see *“What were you trying to do?”* ### Logs ```shell $ curl -i -X GET -b "preferred_frontend=pleroma-fe/stable;" https://ihatebeinga.live/api/v1/akkoma/api/v1/akkoma/preferred_frontend/available HTTP/2 400 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 age: 0 alt-svc: h3=":443"; ma=2592000 cache-control: max-age=0, private, must-revalidate content-security-policy: upgrade-insecure-requests;style-src 'self' 'nonce-sQdsIMmNgbZMxkT';font-src 'self';script-src 'self' 'nonce-sQdsIMmNgbZMxkT' ;connect-src 'self' https://ihatebeinga.live wss://ihatebeinga.live https://media.ihatebeinga.live https://media.ihatebeinga.live https://captcha.ihatebeinga.live;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: Tue, 25 Jul 2023 15:51:38 GMT permissions-policy: interest-cohort=() referrer-policy: same-origin server: Caddy server: Cowboy via: 1.1 ihatebeinga.live (Varnish/7.2) x-content-type-options: nosniff x-frame-options: DENY x-permitted-cross-domain-policies: none x-request-id: F3UnKpGkKHNt31IAJ6Ri x-varnish: 16482848 x-xss-protection: 0 content-length: 157 {"error":"Missing field: frontend_name.","errors":[{"message":"Missing field: frontend_name","source":{"pointer":"/frontend_name"},"title":"Invalid value"}]} ``` ### Severity I can manage (just wanted to let you know since this doesn't seem intentional) ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.