feat: add authz policy types to _meta GraphQL API#852
Open
pyramation wants to merge 2 commits intomainfrom
Open
feat: add authz policy types to _meta GraphQL API#852pyramation wants to merge 2 commits intomainfrom
pyramation wants to merge 2 commits intomainfrom
Conversation
- Add AuthzGrantMeta and AuthzPolicyMeta TypeScript interfaces - Add MetaAuthzGrant and MetaAuthzPolicy GraphQL types - Add authz field to MetaTable for policy introspection via _meta query - Supports role-based scoping (full config for admins, type+description for users)
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds authorization policy metadata to the
_metaGraphQL introspection API, allowing clients to query@authzpolicy information on tables. This is the constructive side of a cross-repo feature — the companion PR inconstructive-dbimplements the SQL infrastructure (policy ↔ smart tag sync, validation, permission simulation).Changes:
AuthzGrantMeta,AuthzPolicyMetaintypes.tsMetaAuthzGrant,MetaAuthzPolicyingraphql-meta-field.tsauthzfield onMetaTable(nullable list ofMetaAuthzPolicy)authz-meta-builder.ts— reads@authzsmart tags from PostGraphile codec extensions (codec.extensions.tags.authz) and transforms them intoAuthzPolicyMeta[]with human-readable descriptionstable-meta-builder.tssocollectTablesMeta()populatesauthzon eachTableMetaHow population works:
buildAuthzMeta(codec)readscodec.extensions.tags.authz(where PostGraphile v5 stores smart tags fromCOMMENT ON), parses the@authzJSON array, and maps each entry to anAuthzPolicyMetawith a generateddescriptionstring. A hardcodedPOLICY_DESCRIPTIONSmap covers all known Authz node types (AuthzDirectOwner,AuthzEntityMembership,AuthzAllowAll, etc.) with context-aware messages like "Requires membership on entity referenced by owner_id with admin_group permission". Unknown policy types fall back to the type name itself.What this does NOT include yet:
authzis exposed unconditionally onMetaTableReview & Testing Checklist for Human
codec.extensions.tags.authzis actually populated: The builder reads smart tags from PostGraphile's codec extensions. Confirm that@authztags written toCOMMENT ON TABLEby the constructive-db write-back trigger flow through PostGraphile introspection intocodec.extensions.tags.authz. If PostGraphile stores the tag differently (e.g., as a flat string vs. parsed JSON), the parsing logic inbuildAuthzMetamay need adjustment.PgCodecWithTagstype cast:buildAuthzMetacastsPgCodectoPgCodecWithTagsto accessextensions.tags. The existingPgCodectype intypes.tsonly declaresextensions.pg— verify this cast is safe and doesn't mask type errors elsewhere.POLICY_DESCRIPTIONScoverage: The description map is hardcoded against knownnode_type_registryentries. If new Authz node types are added in the DB, they'll get the type name as their description (fallback). Confirm this fallback is acceptable.authzis exposed to all users unconditionally. Before production use, this needs scoping so anonymous/unauthenticated users don't see policy metadata.buildAuthzMetawith sample tag data.Recommended test plan:
@authzsmart tag to a table viaCOMMENT ON TABLE ... '@authz [{"policy_type":"AuthzAllowAll","grants":[["select","authenticated"]]}]'{ _meta { tables { name authz { policyType description grants { privilege role } permissive } } } }authzarray; tables without tags returnnullNotes
constructive-dbcompanion PR adds:validate_authz_tag(),rebuild_table_authz_tags(), policy write-back trigger,compile_authz_tags()bridge,check_table_permission()simulation, andparse_comment_to_smart_tags().authzfield is nullable (notnn()), so existing queries won't break — tables without@authztags returnnull.descriptionis NonNull onMetaAuthzPolicyTypebutdescribePolicy()always returns a string (falling back to the policy type name), so this is safe as long as population only goes throughbuildAuthzMeta.Link to Devin session: https://app.devin.ai/sessions/8a124626a9f04ee9ac2f608b77d2921b
Requested by: @pyramation