)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"a5f2d723901cadeea4e70b8d3371188a050bf6f3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"e2d3255b_4800773d","updated":"2026-10-25 16:42:38.000000000","message":"I wanted to flag up the possibility of running keystone auth w/ s3token with multiple auth providers in the pipeline while this is still WIP.\n\nMost cluster\u0027s I\u0027ve seen run with multiple authentication providers, they all use a pattern similar to tempauth (and keystone-authtoken/s3token with `delay_auth_decision\u003dtrue`) - but since that is a non-default option for keystone mw, I can\u0027t for SURE how common it is - but IIUC many popular swift features like tempurl and formpost *require* keystone to be configured with `delay_auth_decision\u003dtrue` so it may not be *UN*common.  YMMV.\n\nWe can certainly document legacy_auth\u003dFalse as *incompatible* with `delay_auth_decision\u003dtrue`/tempurl if that\u0027s the policy we want; but we should state that explicitly.","commit_id":"22b1727c26cf6e1db946afb18f365d9906d43547"}],"swift/common/middleware/s3api/s3token.py":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"a5f2d723901cadeea4e70b8d3371188a050bf6f3","unresolved":true,"context_lines":[{"line_number":479,"context_line":"            self._logger.debug(msg)"},{"line_number":480,"context_line":"            return self._app(environ, start_response)"},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"        if self._auth_mode \u003d\u003d \u0027signing_key\u0027:"},{"line_number":483,"context_line":"            return self._call_signing_key(req, account, start_response)"},{"line_number":484,"context_line":"        if s3_auth_details.get(\u0027signature_version\u0027) \u003d\u003d \u00272\u0027:"},{"line_number":485,"context_line":"            if not self._allow_legacy_signatures:"}],"source_content_type":"text/x-python","patch_set":1,"id":"8dbf8638_fb4fe37c","line":482,"updated":"2026-10-25 16:42:38.000000000","message":"Signing-key mode breaks `delay_auth_decision\u003d\u0027true\u0027` here.\n\n`s3api.auth_details` is the common exchange variable; tempauth also uses it to validate its users’ signatures. Its presence does not establish that Keystone owns the credential.\n\nThe sq? example (https://review.opendev.org/q/Icf8ea3e86c1058a62816bf3b4e6ae85ffd6042c9) exercises real s3api and tempauth with mocked Keystone HTTP and storage. With deferral enabled and Keystone returning 403, legacy mode lets tempauth authenticate its valid request; signing-key mode rejects it without calling tempauth. The tests also demonstrate downstream default denial for unknown credentials and bad signatures.\n\nTempauth distinguishes definitive rejection from deferral with default denial (https://opendev.org/openstack/swift/src/commit/3129f9c186328307cf26c2d2923428a95a2f1c73/swift/common/middleware/tempauth.py#L325). Preserving that cooperation does not require a fallback to Keystone’s legacy exchange. A generic exchange 403 does not distinguish unknown credentials from bad proofs for Keystone-owned credentials. If there is an ownership guarantee here that the example misses, please point it out.","commit_id":"bda3843cc11b5350619b6bcb14bc63d0e1689578"}]}