auth 2.5.0__tar.gz → 2.5.1__tar.gz

{auth-2.5.0 → auth-2.5.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: auth
-Version: 2.5.0
+Version: 2.5.1
 Summary: Authorization for humans
 Author-email: Farshid Ashouri <farsheed.ashouri@gmail.com>
 License-Expression: MIT
@@ -124,9 +124,10 @@ with Client(api_key=KEY, service_url="https://auth.rodmena.app") as c:
   key backs is scheduled for decommission. The opt-in phase is live (2.5.0):
   `PUT /api/settings {"strict_users": true}` makes keyless users answer
   negatively (`user_not_key_backed`), and `POST /api/apikeys/check_permission`
-  does validate + permission in one round trip. **3.0.0 makes key-backed users
-  mandatory** — only after every consuming platform confirms.
-  Details: [docs/DEPRECATIONS.md](docs/DEPRECATIONS.md).
+  does validate + permission in one round trip. **3.0.0 makes strict identity
+  the default** (the audited per-tenant opt-out survives for validated
+  machine-subject architectures) — and ships only after every consuming
+  platform confirms. Details: [docs/DEPRECATIONS.md](docs/DEPRECATIONS.md).
 
 ## Documentation
 

{auth-2.5.0 → auth-2.5.1}/README.md

@@ -68,9 +68,10 @@ with Client(api_key=KEY, service_url="https://auth.rodmena.app") as c:
   key backs is scheduled for decommission. The opt-in phase is live (2.5.0):
   `PUT /api/settings {"strict_users": true}` makes keyless users answer
   negatively (`user_not_key_backed`), and `POST /api/apikeys/check_permission`
-  does validate + permission in one round trip. **3.0.0 makes key-backed users
-  mandatory** — only after every consuming platform confirms.
-  Details: [docs/DEPRECATIONS.md](docs/DEPRECATIONS.md).
+  does validate + permission in one round trip. **3.0.0 makes strict identity
+  the default** (the audited per-tenant opt-out survives for validated
+  machine-subject architectures) — and ships only after every consuming
+  platform confirms. Details: [docs/DEPRECATIONS.md](docs/DEPRECATIONS.md).
 
 ## Documentation
 

{auth-2.5.0 → auth-2.5.1}/auth/docs_page.py

@@ -147,13 +147,19 @@ secrets keep validating afterwards.
 That is being retired. **Since 2.5.0 the opt-in phase is live**: enable strict
 mode with `PUT /api/settings` `{{"strict_users": true}}` and authorization
 decisions about users with no active API key answer negatively (same response
-shapes, additive reason `user_not_key_backed`); membership adds for key-less
-users return `{{"result": false}}` — create the key first, then grant roles.
-Strict mode never blocks key issuance or any delete/revoke path. 3.0.0 makes
-strict identity the default, and ships only after every consuming platform has
-confirmed readiness. Migrate now: issue keys to your users, derive the user
-from `/api/apikeys/validate` — or do both steps in one round trip with
-`POST /api/apikeys/check_permission`.
+shapes, additive reason `user_not_key_backed`). Gated decisions: has_permission,
+the membership check, user_permissions (answers `count: 0` + reason), workflow
+can_run. NOT gated: user_roles, members and every other listing. Membership
+adds for key-less subjects answer **409** `{{"result": false, "reason":
+"user_not_key_backed"}}` (since 2.5.1 — a refused grant must not look like
+success; check `result` on writes regardless). Create the key first, then grant
+roles: key creation committing before the grant is a contract, with no eventual
+consistency in between. Strict mode never blocks key issuance or any
+delete/revoke path. 3.0.0 makes strict identity the default — the audited
+per-tenant opt-out survives for platforms that authenticate their own callers —
+and ships only after every consuming platform has confirmed readiness. Migrate
+now: issue keys to your users, derive the user from `/api/apikeys/validate` —
+or do both steps in one round trip with `POST /api/apikeys/check_permission`.
 
 ## 4. Endpoints
 

{auth-2.5.0 → auth-2.5.1}/auth/routes.py

@@ -194,7 +194,13 @@ def register_routes(app):
         if not result:
             reason = _strict_reason(auth_service, user)
             if reason:
-                return jsonify({"result": result, "reason": reason})
+                # 409, not 200-with-false: two consumers independently showed
+                # that a refused grant answering 200 gets written past
+                # (raise_for_status passes, result goes unchecked) and turns
+                # strict mode into silent dead-key provisioning. Strict mode is
+                # opt-in, so the shape may differ there; the documented
+                # missing-role 200-false below is untouched.
+                return jsonify({"result": False, "reason": reason}), 409
 
         return jsonify({"result": result})
 

{auth-2.5.0 → auth-2.5.1}/auth.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: auth
-Version: 2.5.0
+Version: 2.5.1
 Summary: Authorization for humans
 Author-email: Farshid Ashouri <farsheed.ashouri@gmail.com>
 License-Expression: MIT
@@ -124,9 +124,10 @@ with Client(api_key=KEY, service_url="https://auth.rodmena.app") as c:
   key backs is scheduled for decommission. The opt-in phase is live (2.5.0):
   `PUT /api/settings {"strict_users": true}` makes keyless users answer
   negatively (`user_not_key_backed`), and `POST /api/apikeys/check_permission`
-  does validate + permission in one round trip. **3.0.0 makes key-backed users
-  mandatory** — only after every consuming platform confirms.
-  Details: [docs/DEPRECATIONS.md](docs/DEPRECATIONS.md).
+  does validate + permission in one round trip. **3.0.0 makes strict identity
+  the default** (the audited per-tenant opt-out survives for validated
+  machine-subject architectures) — and ships only after every consuming
+  platform confirms. Details: [docs/DEPRECATIONS.md](docs/DEPRECATIONS.md).
 
 ## Documentation
 

{auth-2.5.0 → auth-2.5.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "auth"
-version = "2.5.0"
+version = "2.5.1"
 description = "Authorization for humans"
 readme = "README.md"
 requires-python = ">=3.9"

{auth-2.5.0 → auth-2.5.1}/tests/test_strict_users.py

@@ -134,9 +134,19 @@ def test_strict_blocks_membership_add_but_never_removal(client):
     _seed_rbac(client, key, user="bob")  # bob is a member while strict is off
     client.put("/api/settings", headers=h, json={"strict_users": True})
 
-    # Adds for keyless users are refused with the 200-false convention.
-    add = client.post("/api/membership/carol/engineers", headers=h).get_json()
-    assert add == {"result": False, "reason": "user_not_key_backed"}
+    # Adds for keyless users are refused with an unmissable 409 (a 200 here
+    # was shown by two consumers to be silently written past).
+    add = client.post("/api/membership/carol/engineers", headers=h)
+    assert add.status_code == 409
+    assert add.get_json() == {"result": False, "reason": "user_not_key_backed"}
+    # The documented missing-role no-op keeps its 200-false shape even in
+    # strict tenants — only the key-less refusal is a 409.
+    ghost_role = client.post("/api/membership/carol/ghosts", headers=h)
+    assert ghost_role.status_code == 409  # carol is still key-less: strict wins
+    client.post("/api/apikeys/user/dave", headers=h)
+    keyed_ghost = client.post("/api/membership/dave/ghosts", headers=h)
+    assert keyed_ghost.status_code == 200
+    assert keyed_ghost.get_json() == {"result": False}
 
     # Removal is NEVER strict-gated: revocation must always work.
     rm = client.delete("/api/membership/bob/engineers", headers=h).get_json()