WP Manifestindependent plugin directory
manifest / integrations / plugin-openpub-internal-data

OpenPub Internal Data WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

OpenPub Internal Data Plugin

★ 0stars
219composer installs
v2.1.5latest · 4mo ago

Install

Download source zip No release zip yet

This is the repository archive. It installs, but the folder name will carry the branch suffix and updates will not flow.

Install straight from GitHub with WP-CLI:

wp plugin install https://github.com/openwebconcept/plugin-openpub-internal-data/archive/refs/heads/master.zip

On Packagist as plugin/openpub-internal-data:

composer require plugin/openpub-internal-data
No built-in updater. New versions won't appear under Dashboard → Updates. Install new releases yourself, or let Git Updater track the repository.

This plugin is inspired by the pdc-internal-products plugin

Core functionality

The plugin adds private fields to openpub items and includes them with authenticated requests.

// ...
"internal-data": [
    {
        "title": "This is internal data, only visible when authenticated",
        "content": "<p>With html, editable in gutenberg</p>\n"
    }
],
"links": [],
// ...

Notable difference!

The plugin does not create endpoints for /internal products, and merely acts as a proxy for the base plugin. The plugin handles any incoming openpub request, and if the request is authenticated the plugin will include internal data.

Setup

You will have to edit the portal codebase to include basic auth credentials when a user is logged in. One of the methods is to create a new singleton looking like this:

// OpenPubServiceProvider.php

$this->app->singleton('openpub.items.internal', function ($app) {
    $config = [
        'base_uri' => env('OPENPUB_ENDPOINT'),
    ];

    if (env('OPENPUB_APPLICATION_USERNAME') && env('OPENPUB_APPLICATION_PASSWORD')) {
        $config['auth'] = [
            env('OPENPUB_APPLICATION_USERNAME'),
            env('OPENPUB_APPLICATION_PASSWORD'),
        ];
    }

    return new Repository(new Client($config));
});

And make sure to use this when the user is authenticated, for example like this:

// OpenPubController.php

public function show(Request $request, $title)
    {
        if (\is_user_logged_in()) {
            $repository = app()->make('openpub.items.internal');
        } else {
            $repository = app()->make('openpub.items');
        }

        // etc

Auth

Similar to pdc-internal-products this plugin uses application passwords to validate authenticated users. You can create an application password in the admin dashboard, see the wp docs

Provide the credentials in the .env file of the portal using

OPENPUB_APPLICATION_USERNAME=
OPENPUB_APPLICATION_PASSWORD=

Make sure your credentials are valid, else the request will result in a 401 and the pub item will not be displayed.

Releases

2 releases.

Tag
Published
v2.1.5 latest
Jun 2, 2026 4mo ago
Apr 5, 2024 2 years ago

These releases are tags only. The author does not attach a packaged zip, so there are no download counts to report.

D+ grade

Security

OpenPub Internal Data 2.1.5 · audited by WP Registry

High-severity findings.

2 high
Audited release
2.1.5
Findings
2
Worst severity
high
Content hash
64abbec45bb3b01d9909d71d…

Findings

  • high OpenPub Internal Data fields publicly readable via REST

    missing_permission_callback

    Plugin header claims it 'Adds internal data to authenticated requests', but RestAPIServiceProvider registers owc/openpub/v1 items routes with permission_callback __return_true, and DataServiceProvider::register always attaches the internal-data field (condition closure returns true). InternalItemsController::addFields() loads DataField which returns internaldata_key/value from post meta _owc_openpub_internaldata to unauthenticated callers.

    src/InternalData/RestAPI/RestAPIServiceProvider.php:40-62

    Recommendation

    Require authentication (and ideally a capability) on routes that include internal-data, or only register the field when is_user_logged_in()/current_user_can matches the documented intent.

  • high Internal-data field condition always true

    information_disclosure

    DataServiceProvider comment says fields should apply 'when in admin or if accessed via the /internal endpoint', but the addGlobalField condition closure unconditionally returns true, so internal WYSIWYG content is attached on every public items response.

    src/InternalData/Data/DataServiceProvider.php:22-27

    Recommendation

    Restore the intended gate (admin or authenticated /internal consumer) instead of return true.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.