API post requests CORS failures when origin is a Firefox extension

[fireph]

Have you read the documentation?

• [x] Yes, but it does not include related information regarding my question.
• [ ] Yes, but the steps described in the documentation do not work on my machine.
• [ ] Yes, but I am having difficulty understanding it and want clarification.

You are setting up gotify in

• [x] Docker
• [ ] Linux native platform
• [ ] Windows native platform

Describe your problem I have set up Gotify with CORS with these environment variables in docker:

GOTIFY_SERVER_CORS_ALLOWORIGINS=[.*]
GOTIFY_SERVER_CORS_ALLOWMETHODS=[POST]

and I can now do a fetch("<url>", {method: "POST"}) in the Firefox dev console (the dev console fetch fails when the env vars are not defined). But once I try to do a post request inside of a Firefox addon (Pageprobe in this case), the post requests start failing with cross origin errors. This is the most info I could get from the fetch that happens inside of the extension:

I am wondering if the weird format of the origin moz-extension://... is causing some sort of issue with how Gotify handles CORS. I have previously set up pushover notifications (https://api.pushover.net/1/messages.json) inside of Pageprobe without issues, so it should be possible to fix this. Any help would be appreciated!

[eternal-flame-AD]

I think browser extensions have some quirkyness to CORS? You might need to add the URL to your add-on manifest or there is a different issue with your add-on configuration, seems like Firefox override the allow origin header from gotify . Since a normal cross origin fetch works can you post your manifest?

[fireph]

It isn't really feasible to modify the extension since I am using https://addons.mozilla.org/en-US/firefox/addon/pageprobe and modifying it would be tricky and I would rather not maintain a fork of it (and it shouldn't be required since other URLs work fine). I tried modifying it to be GOTIFY_SERVER_CORS_ALLOWMETHODS=[POST, GET, OPTIONS] since some comments on StackOverflow talked about Firefox addons running an OPTIONS request before the actual request (but that didn't seem to resolve it). Having this not working is a deal breaker for me so I might just have to put this on the back burner and keep using pushover until I can find a solution. :(

[jmattheis]

Are you sure it's cors? Could you show the cors error? The request you listed returned 400. The browser either shouldn't create a request because the OPTIONS request fails, or gotify will return 403 if the internal cors check fails.

You are sending the message as query parameter, but the content-type is application/json. Without a json request body, gotify will respond 400 here.

$ curl -X POST 'http://localhost:8080/message?token=AH58GAASAYTTsn9&message=abc' -H 'Origin: moz-extension://aeounaotheurahp' -H 'Content-type: application/json' -v
* Host localhost:8080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8080...
* Connected to localhost (::1) port 8080
* using HTTP/1.x
> POST /message?token=AH58GAASAYTTsn9&message=abc HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.11.0
> Accept: */*
> Origin: moz-extension://aeounaotheurahp
> Content-type: application/json
>
* Request completely sent off
< HTTP/1.1 400 Bad Request
< Access-Control-Allow-Origin: moz-extension://aeounaotheurahp
< Content-Type: application/json
< Vary: Origin
< Date: Fri, 22 Nov 2024 08:45:41 GMT
< Content-Length: 64
<
* Connection #0 to host localhost left intact
{"error":"Bad Request","errorCode":400,"errorDescription":"EOF"}

[fireph]

Ah you are totally right, Pageprobe is adding json to the post request that can't be removed:

{
    "value1": "<Tracker URL>", 
    "value2": "<Tracker Name>", 
    "value3": "<Converted Value>[: <Optional Custom Notification message>]"
}

And I assume that gotify is returning 400 since these aren't valid arguments for gotify. Definitely a specialty use case to have a gotify post request that completely ignores any json given. I might just have to create a fork of Pageprobe and remove the json from the "HTTP POST URL" action.

[jmattheis]

If you can adjust the content-type header, to something not application/json your request should work, even if there is an invalid json body.

[fireph]

omg it works, thank you so much for the help!