Quart-CORS

Warnings

• breaking When `allow_credentials=True`, the `allow_origin` parameter MUST NOT be a wildcard (`*`). Instead, it must be a specific origin or a list of specific origins, as required by the CORS specification for security reasons.
  Fix: If `allow_credentials` is true, explicitly list all allowed origins (e.g., `allow_origin=['https://your-frontend.com']`) instead of using `'*'`.
• gotcha Aggressive browser caching (especially in Chrome) can lead to CORS errors persisting even after server-side fixes are deployed. Browsers might cache preflight `OPTIONS` responses, leading to outdated CORS headers being used.
  Fix: Clear browser cache (especially for the affected domain) or disable cache in browser developer tools (Network tab) when debugging CORS issues. Consider setting appropriate `Access-Control-Max-Age` headers on your server.
• breaking As of Quart 0.11.1, the CORS specification dictates that only a single origin (or a wildcard) can be returned in the `Access-Control-Allow-Origin` header. If multiple specific origins are allowed by `quart-cors`, the library will dynamically set the header to the requesting origin if it's in the allowed list.
  Fix: Ensure your frontend understands this behavior. `quart-cors` handles this dynamically for you if you provide a list of allowed origins, but be aware that the browser will only see one origin in the response header.
• breaking Attempting to use `Flask-CORS` with a Quart application will not work, as `Flask-CORS` relies on synchronous `app.make_response` calls which are incompatible with Quart's async nature.
  Fix: Always use `quart-cors` for Quart applications to ensure proper asynchronous handling of CORS headers.
• gotcha While `quart-cors` is generally backward compatible with `Quart`, ensure that `quart` and `quart-cors` versions are reasonably aligned. Significant version jumps of `Quart` might introduce subtle incompatibilities.
  Fix: Regularly update both `quart` and `quart-cors`. If encountering unexpected behavior after an update, check the changelogs for both libraries for any breaking changes or specific compatibility notes.

Install

• pip install quart-cors Install with pip

Imports

• cors

  from quart_cors import cors

  Used to apply CORS settings application-wide or to a blueprint.
• route_cors

  from quart_cors import route_cors

  Decorator for applying CORS settings to individual HTTP routes.
• websocket_cors

  from quart_cors import websocket_cors

  Decorator for applying CORS settings to individual WebSocket handlers.
• cors_exempt

  from quart_cors import cors_exempt

  Decorator to exempt a route or WebSocket handler from global CORS settings.

Quickstart

This quickstart demonstrates how to initialize a Quart application and apply CORS globally using `cors(app, allow_origin='*')`. It also shows how to use the `route_cors` decorator to apply more specific CORS rules to an individual API endpoint, allowing GET and POST requests from a specific origin with custom headers. Remember to replace `allow_origin='*'` with specific origins in production for security.

from quart import Quart, request
from quart_cors import cors, route_cors

app = Quart(__name__)

# Apply CORS to the entire application, allowing all origins
# For production, specify allowed origins instead of '*'
app = cors(app, allow_origin='*')

@app.route('/')
async def hello():
    return 'Hello, Quart-CORS!'

@app.route('/api/data', methods=['GET', 'POST'])
@route_cors(allow_origin='https://example.com', allow_methods=['GET', 'POST'], allow_headers=['Content-Type'])
async def api_data():
    if request.method == 'GET':
        return {'message': 'This is your data!'}
    elif request.method == 'POST':
        data = await request.get_json()
        return {'received': data, 'message': 'Data posted successfully!'}

if __name__ == '__main__':
    app.run()