Conversation
Merged into jem-dev for branch-only release train.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fe81741ea3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| payload = service.revoke_share( | ||
| share_euid, | ||
| revoked_by=str(profile.get("email") or "").strip(), | ||
| reason=str(form.get("reason") or "").strip() or None, |
There was a problem hiding this comment.
Check ownership before revoking UI shares
Any signed-in UI user can reach this handler and revoke the supplied share_euid; there is no replacement for the previous admin-or-issuer check before calling service.revoke_share. Since /shares lists active shares to regular UI users, this lets one user disable another user's share just by pressing the Revoke action or posting the share id.
Useful? React with 👍 / 👎.
| ) | ||
| self._append_share_audit(session, share, event) | ||
| raise PermissionError("share access denied") | ||
| ttl_limit = max(60, int(signed_ttl_seconds or payload.get("default_signed_ttl_seconds") or self.share_default_signed_ttl_seconds)) |
There was a problem hiding this comment.
Cap signed package TTL at the share expiry
When a share expires sooner than the requested/default signed TTL, this uses the requested TTL unchanged and passes it to S3/CloudFront signing, so a caller can mint access URLs or cookies that remain valid after the Dewey share has expired. The old share-reference path capped presign TTL by seconds_remaining; this path should similarly clamp ttl_limit to the remaining share lifetime before signing.
Useful? React with 👍 / 👎.
| if is_ai_agent_token(token): | ||
| try: | ||
| grant = validate_ai_agent_request(request, token) |
There was a problem hiding this comment.
Wire AI-agent tokens into the route auth dependencies
This AI-token branch is only inside require_observability_access, but the cataloged artifact/search endpoints are protected by api_auth_dep or session_or_api_auth_dep; observability routes are not in ENDPOINT_CATALOG, so a kahlo_ai_ token is rejected everywhere rather than being validated for the advertised read-only endpoints. In an AI-agent-enabled deployment, allowed agents therefore cannot read any of the Dewey endpoints this feature is meant to expose.
Useful? React with 👍 / 👎.
| EndpointSpec("dewey.artifacts.list", "GET", "/api/v1/artifacts"), | ||
| EndpointSpec("dewey.artifacts.detail", "GET", "/api/v1/artifacts/{artifact_euid}"), | ||
| EndpointSpec("dewey.artifacts.graph", "GET", "/api/v1/artifacts/{artifact_euid}/graph"), | ||
| EndpointSpec("dewey.search.query", "POST", "/api/v1/search/query"), |
There was a problem hiding this comment.
Point AI search grants at the live search route
dewey.search.query is registered for /api/v1/search/query, but this app exposes the search query route at /api/search/v2/query and has no /api/v1/search/query route. A grant containing dewey.search.query will therefore fail endpoint matching on the actual search API even after AI-token auth is wired into that route.
Useful? React with 👍 / 👎.
| @db_app.command("verify-templates") | ||
| def verify_templates() -> None: |
There was a problem hiding this comment.
Register the new template commands
Defining verify-templates and repair-templates on db_app is not enough for the shipped dewey entry point: dewey_service.cli:main builds commands from the explicit register_group_commands list below, and these new callbacks are not added there. Operators will not be able to run dewey db verify-templates or dewey db repair-templates when the new template verification/repair flow is needed.
Useful? React with 👍 / 👎.
Scope
Release
dewey-service7.0.2fromjem-devtomainfor the Dayhoff main roll-up.# nosec B303on CloudFront RSA-SHA1 signing; CloudFront signed policy/cookie signing requires this algorithm.7.0.0,7.0.1,7.0.2. Use7.0.2for Dayhoff pins.Local validation
ruff check dewey_service tests-> passruff format --check dewey_service tests-> passbandit -c pyproject.toml -r dewey_service-> passsource ./activate codrel && DAYHOFF_PROJECT_ROOT=/Users/jmajor/projects/mega_dayhoff/dayhoff ./.venv/bin/python -m pytest tests -q-> pass, 2 skippedMerge policy
Merge normally when GitHub checks and review policy allow it. Do not use admin merge or force-push.