A version written into a manifest is written into every manifest that wants it, which is how eslint came to exist in a hundred and four forms across this estate and how a package came to resolve twice at run time. The catalog moves the number out of the manifest: a manifest names the package, the workspace names the version. Four are held below their latest because the newer release cannot be used, and the reason is recorded rather than the version alone: @noble/hashes 2 renamed every subpath the web3 stack imports, @splinetool/runtime 2 depends on a package that was never published, @dynamic-labs 5.4.1 the same, and react-resizable-panels 3 points its types condition at the bundle.
CSP Violations Playground
A development playground for testing CSP violation reports with Insights.
Setup
Before running the playground, make sure to update the required env variables for server.js to work:
Create a .env file in the root directory with the following variables:
INSIGHTS_PROJECT_API_KEY=your_insights_token
INSIGHTS_API_HOST=your_insights_api_host # e.g., https://app.insights.hanzo.ai
INSIGHTS_UI_HOST=your_insights_ui_host # e.g., https://app.insights.hanzo.ai
INSIGHTS_USE_SNIPPET=true # if you want to include the insights snippet on the playground pages to track pageviews, etc.
These environment variables are required for the playground to work correctly. The server will fail to start if they are not properly configured.
Installation
Install the dependencies:
pnpm i
Running the Playground
pnpm dev
This uses nodemon to automatically restart the server when you make changes to the files.
Usage
Once the server is running, open your browser and navigate to:
http://localhost:8080
The playground includes examples for different types of CSP violations:
Basic CSP Violations
- Inline Script Violation - Tests violations of inline scripts
- External Script Violation - Tests loading scripts from non-allowed domains
- External Image Violation - Tests loading images from non-allowed domains
- External Style Violation - Tests loading stylesheets from non-allowed domains
- XHR Violation - Tests making XHR requests to non-allowed domains
- Eval Violation - Tests scripts with
evalpresent
Report-To Debug Cases
These test cases are specifically designed to debug report-to directive issues and test the logging functionality added in PR #32868:
- Debug Enabled - Tests CSP reports with
debug=trueparameter for verbose logging - Invalid Content Type - Tests CSP reports sent with incorrect content type to trigger error logging
- Report-URI Only - Tests pages using only
report-uridirective (noreport-to) - Report-To Only - Tests pages using only
report-todirective (noreport-uri) - Both Report Directives - Tests pages using both
report-uriandreport-todirectives - Malformed Reporting Endpoints - Tests malformed
Reporting-Endpointsheader to trigger error logging - Sampling Test - Generates multiple violations rapidly with random query parameters and hashes to bypass URL-based sampling and test sampling behavior and logging
Each example will automatically trigger a CSP violation when the page loads, which will be reported to your configured CSP endpoint.
How it Works
The server sets a Content Security Policy header that restricts what resources can be loaded. When a resource violates this policy, the browser will send a report to the specified report-uri endpoint.
This playground is useful for testing how CSP violation reports are processed by your Insights instance.