- Can the code replace the
AllowOriginmiddleware in the tiddlyspace code?
- If we do either preflight checks (via
OPTIONS) or allow auth over CORS (via
Access-Control-Allow-Credentials) are we opening a big security hole on TiddlySpace? Transcribed (with edits) from the emails:
I suspect it would be okay to enable cors preflight in a tiddlyweb installation that was a single domain, but the CORS exchanges that could do writes, in the tiddlyspace multi-domain environment, have the potential to be a big mess (bigger than the existing mess).
The main scenario goes something like this:
- I visit space X as user Y.
- Space X runs code which delete's Y's stuff, as user Y, without Y knowing about it and without X ever knowing Y's auth credentials (the browser, executing the code, knows the credentials).
Right now, code in space X can only (usually) write to entities that are part of space X. CORS control prevents PUTs and DELETEs to other domains, and the server-side
DropPrivsmiddleware makes sure that operations against entities which are only included in (not natively a part of) space X happen only as GUEST.
Someone using curl would need to know user Y's credentials to have
Of course this discussion has happened so many times there may be
errors or omissions that mean it's wrong...