20120414

Started working on a tiddlywebplugins.cors following discussion with neumark.

In that discussion I expressed some concerns:

• Can the code replace the AllowOrigin middleware 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 DropPrivs middleware makes sure that operations against entities which are only included in (not natively a part of) space X happen only as GUEST.

It's messy.

Someone using curl would need to know user Y's credentials to have
similar powers.

Of course this discussion has happened so many times there may be
errors or omissions that mean it's wrong...

Syndicated 2012-04-14 17:06:01 (Updated 2012-04-14 17:06:39) from cdent