-
-
Notifications
You must be signed in to change notification settings - Fork 645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
403 when passing Origin header with Environment config #633
Comments
Unfortunately i don't have access to the config file (actually, there is no config file, its all managed via env variables). It's running via Caprover which uses Docker under the hood. No access to the Dockerfile. It passes any environment vars through though, and i've checked this with printenv after an interactive shell:
And with the new env:
Caprover does map a volume however, so i did create a simple config there but still no joy. This is the config:
Interstingly, your screenshot doesn't show the preflight OPTIONS call so i guess it assumes its a simple call and skips it. I've switched to vite (from next.js) and axios (rather than fetch) and i am getting the same results. The response from the OPTIONS call is 204 (which is ok), and returns these response headers:
Why is Allowed-Methods still in the env format (as per the docs), and not parsed out to (I removed the X-Gotify-Key header from the call and appended to the url) Log is showing the 204:
Postman continues to work correctly with and without the Origin header being sent, but it doesn't care about cors. |
Don't mix environment config and file config. I've updated the environment config in the docs https://gotify.net/docs/config could you retry it in this format? I've this docker-compose:
with this html script:
This works fine for me, now with the options/preflight request: If you set the environment variables similar to this and it still doesn't work, then caprover does something weird with environment variables. |
Ok. First up, yes, that fixed the Origin issue with the env vars!! So i removed the temp config i made, and set the env vars: And now i can see the correct However, your code with fetch does not work :( But this does:
And so does this:
And this:
If i put the token in the headers it fails, which indicates its something to do with the proxy. I've explicitly tried setting What's more, if i send json it sets the content-type header accordingly and whether i have token in headers or in the QS it causes a preflight cors OPTIONS check and returns 204 and fails cors. So summary: Setting token in Header does not work. Posting as json does not work. Posting with X-Gotify header works in Postman, as does json format!!! And here are the various functions i've used: Fetch requests working / not working/// WORKS
const doFetch1 = async () => {
axios.post(
`${HOST}/message?token=${APP_KEY}`,
{
message: 'urlencoded from react with axios'
},
{
headers: {
'Content-Type': 'multipart/form-data'
},
})
}
/// DOESN't WORK
const doFetch2 = async () => {
fetch(`${HOST}/message?message=x1`, {
method: "POST",
headers: { "x-gotify-key": APP_KEY },
});
}
/// WORKS
const doFetch3 = async () => {
fetch(`${HOST}/message?token=${APP_KEY}&message=x2`, {
method: "POST",
});
}
/// WORKS
const doFetch4 = async () => {
fetch(`${HOST}/message?token=${APP_KEY}`, {
method: "POST",
headers: {
"Content-Type": "application/x-www-form-urlencoded"
},
body: "message=urlencoded from react with fetch"
});
}
/// DOESN'T WORK
const doFetch5 = async () => {
fetch(`${HOST}/message?token=${APP_KEY}`, {
method: "POST",
headers: {
"Content-Type": "application/json"
},
body: { message:"json from react with fetch" }
});
}
/// DOESN'T WORK
const doFetch6 = async () => {
axios.post(
`${HOST}/message?token=${APP_KEY}`,
{
message: 'json content type message'
})
} It's interesting json doesn't work as the library i've used And i haven't even gotten to testing websocket yet, now that message create is working for me :/ |
Have a look at the browser console, it says why the CORS request fails. Headers like With this config requests with json and token inside the header work fine. fetch("http://localhost:8080/message", {
method: "POST",
headers: {
"Content-Type": "application/json",
"X-Gotify-Key": "AgarXhfGWhnzOae",
},
body: JSON.stringify({ message: "json from react with fetch" }),
}); |
🤦♂️Ahhh, i can't believe i missed that, and i was just literally looking at the allowed headers option in the docs!!! Yesss, thank you! Well that about sorts it. Difference between Axios and Fetch is Axios automatically stringifies the data object, fetch doesn't, which is why i just got the bad requests in the console. Oh, i just tested standard websocket to receive messages and its happy now as well with So, the take from this i think is that there either needs to be a section in the docs like
Or those Methods and Headers are allowed by default? (I understand the implications of allowing every Origin, so totally fine to have the user supplied something sensible). However, i do appreciate you updating the docs with the correct format for the env vars, cheers :) |
I'd say adding the allowheaders and allowmethods as defaults shoulds reasonable. |
Have you read the documentation?
You are setting up gotify in
Describe your problem
I have Gotify 2.4.0 running in Docker (using Caprover), with nginx proxy. Web UI runs fine (same origin). Using Postman from Windows also submits messages just fine. The problem is the cors allow origin seems to not be validating the Origin header and logging 403.
I have the following environment variables set (square brackets represent the UI textboxes of Caprover):
The Server is running from
hosting.my-server.com
, and Brave is running fromlocalhost:3000'. Brave passes Origin as
http://localhost:3000/` as it should as its cross-origin. A postman request with NO Origin results in 200 status, but if i add the same Origin header it fails with 403.I have tried a bunch of different origin header values but none of them seem to work. Im guessing nginx proxy is not sending Origin but rather X-Forwarded-For which Gotify isn't reading. Or my regex is wrong. Surely .* will match anything?
Adding 'Access-Control-Allow-Origin' '*' to nginx only replies to the client with accepted, Gotify still logs 403.
What can i do here?
Any errors, logs, or other information that might help us identify your problem
Gotify logs for successful and failed requests:
Proxy settings for nginx:
The text was updated successfully, but these errors were encountered: