Description
I'm running my own instance of ntfy and noticed an issue when trying to configure a bookmarklet in my browser. By default my instance has web-root set to disable in the ntfy config, because I don't want the UI exposed publicly. Generally this works well, however...
I sometimes want to share a link to a page on my browser to my phone via ntfy. I have set up a bookmarklet (simple JS script that gets embedded on the current page to call ntfy with its location/title).
async function postData(topic, data) {
const c = await fetch('https://<url_to_my_instance>/', {
method: "POST",
mode: "cors",
cache: "no-cache",
credentials: "same-origin",
headers: {
'Authorization': 'Basic <redacted_token_here>'
},
redirect: "follow",
referrerPolicy: "origin",
body: JSON.stringify({
'topic': topic,
'message': data.location,
'actions': [{
'action': 'view',
'label': 'Open',
'url': data.location
}],
'title': `URL Shared - ${data.title}`,
'tags': data.tags
})
});
return c.json()
}
postData("url-share", {
location: location.href,
title: document.title,
tags: 'desktop_computer'
}).then(a => {
console.log(a)
}).catch(a => {
console.error("Error:", a)
});
Because of CORS the browser will issue an OPTIONS call to the above URL first to check valid origins. Currently, ntfy only responds on that method if the web-root is not disabled, and otherwise returns a 404 (which causes the browser to refuse to make the actual POST/PUT. I'm curious if that's really necessary. I've confirmed that re-enabling the web-root makes the problem go away. As far as I can tell it would be just a matter of removing ensureWebEnabled here. I'm not sure if there are other implications from doing so. The handleOptions only sets the CORS headers anyway, so that seems fairly innocuous but I may be missing something.