fix: check per-chart edit_post capability in chart_data REST field

[lucadobrescu]

Any logged-in user with the edit_posts capability (Contributor and above) could read the full backend configuration of any chart on the site — data source query, series/settings, and JSON endpoint URLs with their authentication headers — via GET /wp-json/wp/v2/visualizer/{chart_id}, because the chart_data REST field callback only checked the generic edit_posts capability. Reported in Codeinwp/visualizer-pro#605.

What changed

• chart_data REST field guard — get_visualizer_data() now checks current_user_can( 'edit_post', $post['id'] ) against the requested chart instead of the generic current_user_can( 'edit_posts' ). Access now follows the standard post capability map: the chart's author, or users with edit_others_posts (Editor and above).

• Regression test — tests/test-chart-data-permissions.php asserts a Contributor gets false for another user's chart and that the chart author still receives the data.

chart_data request flow

flowchart LR
    A[GET /wp/v2/visualizer/id] --> B[chart_data field callback]
    B --> C{Changed:<br/>can edit_post<br/>this chart?}:::changed
    C -- Yes --> D[Return chart config]
    C -- No --> E[Return false]

    classDef changed fill:#9a6700,color:#fff,stroke:#5c3d00,stroke-width:3px,stroke-dasharray:6 3

Loading

QA

1. As an Administrator, create and publish a chart, and note its post ID.

2. As a Contributor, request the chart over REST (e.g. from the browser console while logged in):

   wp.apiFetch( { path: '/wp/v2/visualizer/<chart_id>' } ).then( console.log );

   Expect: chart_data is false — no source query, settings, or endpoint headers in the response.

3. As the chart's author (or an Editor/Administrator), repeat the same request.
   Expect: chart_data contains the chart configuration and the chart still loads normally in the Gutenberg block editor.

🤖 Generated with Claude Code

[pirate-bot]

Plugin build for 2bcb43e is ready 🛎️!

• Download build