https://github.com/cdent/tiddlywebplugins.cors

Experiment in handing CORS preflight for TiddlyWeb
https://github.com/cdent/tiddlywebplugins.cors

Last synced: about 1 year ago
JSON representation

Experiment in handing CORS preflight for TiddlyWeb

• Host: GitHub
• URL: https://github.com/cdent/tiddlywebplugins.cors
• Owner: cdent
• Created: 2012-04-14T13:48:45.000Z (about 14 years ago)
• Default Branch: master
• Last Pushed: 2014-03-26T23:56:04.000Z (about 12 years ago)
• Last Synced: 2025-02-01T03:28:47.005Z (over 1 year ago)
• Language: Python
• Homepage: http://tiddlyweb.com/
• Size: 156 KB
• Stars: 2
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README

Awesome Lists containing this project

README

          
A plugin for TiddlyWeb to support CORS pre-flight checks.

This is an experiment, with limited functionality. As test

cases increase, functionality will increase.

To use add 'tiddlywebplugins.cors' to 'system_plugins' in 

tiddlywebconfig.py.

There are a few optional config settings:

If 'cors.match_origin' is True, then the value of the Origin

header will be the value of the Access-Control-Allow-Origin header,

on simple requests. On non-simple request, it always matches. If False

the value is '*' (on simple requests).

If 'cors.allow_creds' is True, then the

Access-Control-Allow-Credentials header will be sent with a value

of 'true', otherwise it will not be sent.

If 'cors.exposed_headers' is set, its should be a list of strings

representing header names which are appended to the default

Access-Control-Expose-Headers: ETag. This same list is used to set

the default of Access-Control-Allow-Headers.

If 'cors.enable_non_simple' is True, preflight OPTIONS requests are

handled. This defaults to False to avoid accidental exposure.

For authenticated cross-domain PUTs of resources the following config

appears to be required:

    'cors.enable_non_simple': True,

    'cors.allow_creds': True,

    'cors.match_origin': True,

The match_origin setting is required for the OPTIONS preflight requests

to be handled effectively.

ToDo:

* Blacklist/Whitelist processing of Access-Control-Request-Headers.

* Auditing with someone else to confirm that this stuff is "correct".

* Refactoring of the two middlewares. There's a fair bit of overlap.

  It could become just one that operates on both sides of the internal

  application, but I find that can be confusing.

Copyright 2012, Chris Dent