[bug] language setting causes invalid value for header? #503

Open
opened 2023-03-11 13:10:05 +00:00 by yheuhtozr · 4 comments

Your setup

OTP

Extra details

No response

Version

3.6.0

PostgreSQL version

14

What were you trying to do?

I try to remote repeat or do any interaction with a post through web UI, for example this one:

image

then:

image

What did you expect to happen?

When I input my account ID, it redirects to my instance and the server takes care of it.

What actually happened?

My instance's ostatus_subscribe page displays "Error fetching user", and the following error is logged in my service journal.

I'm not exactly sure it is caused by BE, FE, or my browser's language settings.

Logs

Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not decode user at fetch https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\""
Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not fetch user https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, {nil, {:error, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\""}}

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 3.6.0 ### PostgreSQL version 14 ### What were you trying to do? I try to remote repeat or do any interaction with a post through web UI, for example this one: ![image](/attachments/ee5cd6f3-37a8-421f-9940-a5ea43e069d1) then: ![image](/attachments/449b82fe-f8d3-4cb7-8052-c614e380649f) ### What did you expect to happen? When I input my account ID, it redirects to my instance and the server takes care of it. ### What actually happened? My instance's `ostatus_subscribe` page displays "Error fetching user", and the following error is logged in my service journal. I'm not exactly sure it is caused by BE, FE, or my browser's language settings. ### Logs ```shell Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not decode user at fetch https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\"" Mar 11 21:40:16 ***.net pleroma[350176]: 21:40:16.902 request_id=F0tdy-yhKwBFD5oAA2KB [error] Could not fetch user https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220, {nil, {:error, "invalid value for header (only printable ASCII characters are allowed) \"date\": \"土, 11 3月 2023 12:40:16 GMT\""}} ``` ### 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.
yheuhtozr added the
bug
label 2023-03-11 13:10:05 +00:00

interesting, i wonder if that's caddy doing weird stuff

interesting, i wonder if that's caddy doing weird stuff

curl https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 -D- --header "Accept-Language: ja"
seems to throw back a correctly formatted header
hm

curl https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 -D- --header "Accept-Language: ja" seems to throw back a correctly formatted header hm
Author

Just noticed that when I change my account's interface language (on Akkoma-FE), the error is gone. But now ostatus_subscribe returns "Error following account" and still can't repeat that post. This time there seems no error recorded in the journal or the access log.


FYI:

YOUR.IP.AD.DR - - [12/Mar/2023:12:01:23 +0900] "GET /ostatus_subscribe?acct=https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 HTTP/2.0" 200 511 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0"
Just noticed that when I change my **account's** interface language (on Akkoma-FE), the error is gone. But now `ostatus_subscribe` returns "Error following account" and still can't repeat that post. This time there seems no error recorded in the journal or the access log. --- FYI: ``` YOUR.IP.AD.DR - - [12/Mar/2023:12:01:23 +0900] "GET /ostatus_subscribe?acct=https://ihatebeinga.live/objects/b3505469-0253-4285-a7e0-7f86d8fa3220 HTTP/2.0" 200 511 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0" ```
Contributor

While trying to follow a relay, I encountered the same error. I was able to mitigate it by deactivating the ActivityPub.SignObjectFetch setting.

From what I understand, this bug is encountered on non-english servers because of those lines:

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L271-L276

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L230-L236

https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80

Having the Pleroma.Config.get([:activitypub, :sign_object_fetches]) set to true cause the server to add a Date header on its requests. However, it seems that this date is translated at some point (probably following OS locale settings). On my config it generates lun., 07 août 2023 10:32:16 GMT with "û" not being a valid ASCII char.

This bug seems to be rather important since in the current state, we do not follow the Date HTTP header format in some cases: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date

Here is the fix I'll propose in a PR (https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80):

  def signed_date(%NaiveDateTime{} = date) do
    Timex.lformat!(date, "{WDshort}, {0D} {Mshort} {YYYY} {h24}:{m}:{s} GMT", "en")
  end
While trying to follow a relay, I encountered the same error. I was able to mitigate it by deactivating the `ActivityPub.SignObjectFetch` setting. From what I understand, this bug is encountered on non-english servers because of those lines: https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L271-L276 https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/object/fetcher.ex#L230-L236 https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80 Having the `Pleroma.Config.get([:activitypub, :sign_object_fetches])` set to true cause the server to add a `Date` header on its requests. However, it seems that this date is translated at some point (probably following OS locale settings). On my config it generates `lun., 07 août 2023 10:32:16 GMT` with "û" not being a valid ASCII char. This bug seems to be rather important since in the current state, we do not follow the Date HTTP header format in some cases: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date Here is the fix I'll propose in a PR (https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/lib/pleroma/signature.ex#L78-L80): ``` def signed_date(%NaiveDateTime{} = date) do Timex.lformat!(date, "{WDshort}, {0D} {Mshort} {YYYY} {h24}:{m}:{s} GMT", "en") end ```
Sign in to join this conversation.
No milestone
No project
No assignees
3 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#503
No description provided.