[fcollman]

Problem

configure_app pushed an app context that was never popped. Flask 2.3 reuses an already active app context for a request instead of pushing its own, so flask.g outlived each request within a uWSGI worker process. middle_auth_client's auth_required skips authentication when flask.g.auth_token is already set.

On any endpoint without @reset_auth, a request ran as whoever that worker last authenticated, including a request with no token at all. That covered most of upload/api.py (inspect, start, cancel, status, user-jobs, admin cleanup) and the datastack/table views in views.py. Requests were:

• wrongly refused, such as the intermittent Missing permission: edit for dataset minnie65 from the upload wizard's inspect step;
• or wrongly allowed, with another user's permissions.

Reproduced on minnie (v5.33.0) with the app's test client: a request with a token, then one without, and the second returned 200 as the first user.

Fix

• configure_app no longer pushes an app context. It was added in 2019 (f01dd3d) so early celery tasks could read current_app. Tasks now run in their own context (ContextTask), as do the Ray entrypoints and Ray workers, and the celery signal handlers either don't use the app or push their own context. Code with no context falls back to the environment, as before, through get_config_param.
• create_app registers a before_request hook that clears flask.g.auth_token and flask.g.auth_user, so no endpoint depends on carrying a decorator.
• The per-endpoint @reset_auth decorators are removed.

Tests

tests/test_reset_auth.py:

• shows the leak on an app without the hook;
• checks that, with the hook, a request with no token after an authenticated one gets a 401, and each request runs as its own token's user;
• checks that edit permission follows the request's token;
• checks that configure_app leaves no context pushed.

Full suite on a fresh PostGIS: 701 passed, 2 skipped.

🤖 Generated with Claude Code