Repository navigation
feature request: Add a read-only option for the graphql endpoint #2289
Description
Describe the problem you're trying to solve
Sometimes you may want to grant a toolbar extension a read-only version of your data (allow graphql queries but not mutations) That way you dont need to worry about them calling a mutation to zap or anything because the chrome extensions are allowed to break CORS and have access to cookies
Describe the solution you'd like
Add a query-string parameter readOnly to /api/graphql that defaults false. It can be picked up by middleware and return a http 403 with an error message of operation not allowed if a mutation operation is detected when readOnly=true
Describe alternatives you've considered
- We could make an entirely new endpoint like
/api/graphql-robut I didn't like the idea of having a whole new route just for the readonly version. - Im not sure how I could do it in the host permission of the extension because it doesn't allow me to restrict the arguments sent
- Do nothing - I wasn't a fan because I would like people to be able to trust the tool isn't going to be able to steal sats after some update without some alert of permissions changes
Additional context
- Stacker thread for original conversation: https://stacker.news/items/1037861/r/carter?commentId=1038405
- Documentation on host permission: https://developer.chrome.com/docs/extensions/develop/concepts/declare-permissions#host-permissions
Activity
ekzyis commentedon Jul 17, 2025
I was thinking if we could limit it based on HTTP method. So if
GETis called, it cannot run mutations.But I guess that wouldn't help with the extension since you can't limit based on HTTP method.
But I'm also not sure if adding a param would help? The documentation for match patterns sounds like you can't match params, only paths.
Anyway, we have plans to rethink how we authorize requests (more explicit, granular and easier to verify). We will consider this ticket as part of it.
neopunisher commentedon Jul 17, 2025
That wouldn't be optimum because then the query size would be limited by the url length. It would also break my current implementation https://github.com/neopunisher/hn-stacker-ext/blob/main/background.js#L77 that
POSTs after building the queryOnce the extension is published the urls in the manifest cannot be changed so if you use
https://stacker.news/api/graphql?readOnly=truethen it would always have the param. You can see an example of my current manifest here https://github.com/neopunisher/hn-stacker-ext/blob/main/manifest.json#L7 But you just made me realize if your graphql query is small enough you could put it in the url and then be gaurenteed that only that query is ever run (and still be able to set variables) so that may be a valid solution if you have a small number of queries that don't need to change and aren't very complex