Dash Basic Auth can create conflicts with auth to other services when served under the same origin

[Wiebke]

Problem

We currently (optionally) use Dash Basic Auth with an environment variable–based initialization.

mlex_highres_segmentation/app.py

Lines 23 to 27 in 354dc33

	auth = (
	dash_auth.BasicAuth(app, VALID_USER_NAME_PASSWORD_PAIRS)
	if os.getenv("DASH_DEPLOYMENT_LOC", "") != "Local"
	else None
	)

This turns out to create problems when authenticating with other services that use different mechanisms (e.g. Tiled via API key) but are served from the same origin under different paths in NGINX.

After authenticating to the Dash app, an Authorization header is added to subsequent requests made in the same browser from the same origin. These headers are then rejected (rightfully so) by other services that expect a different authentication method but can be configured to accept Basic Auth.

Setup

• Tiled served under /
• Segmentation (Dash app) served under /segmentation
• Both behind the same NGINX origin

We first encountered this in a scenario with a Dash app using Basic Auth and subsequent API requests to Tiled in the same browser failing authentication. The browser caches Basic Auth credentials and automatically attaches the same Authorization header to all subsequent requests. I assume this happens because the services are considered to be in the same protection space/realm (RFC 7235 § 2.2). We had not configured a realm explicitly, so the protection space defaults to the origin (i.e., same scheme, host, and port as defined in RFC 6454 § 3.2).

Possible Solutions

• Replace dash-auth with a different, external authentication mechanism (planned).
• In local deployments, drop the Authorization header for requests to Tiled (e.g. through NGINX configuration). This is what we are now doing in the referenced deployment, see also Exchange dataset input with tiled_viewer component #198 for other issues related with this.
• Serve services on different subdomains to separate authentication scopes.