Laravel Sql Dashboard Laravel Package

Technical Evaluation

What this package is (as evidenced by v0.1.1): a Laravel package that lets users author and save SQL from a web dashboard, run it against configured connections, share queries/dashboards, and attach scheduled "checks" that raise alerts (mail; Slack described as untested) when a result crosses a threshold (alerts.rows_in_alert). Access is controlled by Laravel gates — a general "use" gate defaulting to app()->environment('local'), and an "edit" gate.

Architecture fit

• Fits a Laravel monolith or an internal admin/back-office service where the package registers a service provider, publishes config/migrations, and hangs routes behind existing auth and gates. It is not a standalone BI product; it assumes Laravel's session/auth/gate model and app-level config for DB connections.
• The security model is layered but fundamentally deny-list plus connection-privilege checks, not a sandbox: a tokenizer normalises quoted/bracketed/back-ticked/schema-qualified function names and refuses PostgreSQL U&"..." escapes, then matches against function families (server-file, large-object, replication, backend-signal, logical decoding, dblink, postgres_fdw, MySQL wait/lock and UDF names). The README now states plainly this is a tokenizer, not a full SQL parser — treat the SQL gate as defence-in-depth, not a trust boundary.
• The second layer is privilege-aware: PostgreSQL roles that are superusers (even on standby), members of pg_read_server_files/pg_write_server_files/pg_execute_server_program/pg_signal_backend, able to execute dblink or server-file functions, or holding USAGE on a foreign server are refused; MySQL users with PROCESS, FILE or SUPER are refused. This is the more durable control: it survives SQL-gate bypasses by shrinking the blast radius to what the role can do.
• Session hygiene: PostgreSQL advisory locks and MySQL GET_LOCK locks are released after each query because they outlive the rolled-back transaction. This is a meaningful architectural detail — it implies queries run inside a transaction that is rolled back, and that the package is aware of session-scoped state. It also implies persistent/reused connections are a consideration.
• SQLite support is only meaningfully hardened on PHP 8.5+, where the authorizer restricts to reads on top of the read-only file handle. On earlier PHP versions the SQLite path has a weaker guarantee.

Integration feasibility

• Low mechanical effort: composer require, publish config and migrations, wire the gates, point at a connection. No external services required for the core loop; Slack/mail are optional.
• The real work is not installation but role design. The package's safety is a joint property of the package and the database role it connects as. That requires a DBA or platform engineer to create a dedicated least-privilege role (ideally on a read replica), verify the package's connection check accepts it, and confirm the check rejects the roles you actually have lying around.
• Requires a scheduler and a queue worker for check evaluation and alert dispatch; an app without schedule:run will silently never alert.
• Config surface is small but moving (alerts.rows_in_alert was only just documented), so expect to re-read published config on each bump.

Technical risk

• Bypass class risk (highest). The 0.1.1 fix is exactly the kind of bug that recurs: a tokenizer's normalisation rules versus a SQL dialect's naming rules (quoting, schema qualification, Unicode escapes, comments, nested dollar-quoting, PREPARE/EXECUTE, DO blocks, CTEs, stored procedures, COPY ... PROGRAM). Each dialect adds surface. Assume further bypasses exist and design so a bypass is survivable.
• Pre-1.0 churn. v0.1.1 as a security patch on a 0.1.x line means API/config instability is expected. No semver guarantee to lean on.
• Self-service SQL is a production-data-exfiltration feature by design. Anyone with the edit gate can edit or delete shared queries, dashboards and checks — the README now says so explicitly. The gate model is coarse: "can edit" is effectively "can change what everyone else sees and what alerts fire."
• Default gate is environment-based, not identity-based. app()->environment('local') is a safe default, but it means the package ships expecting you to replace it. A misconfiguration in a non-local environment is a full-exposure incident, and the release note's own framing ("upgrade if anyone can write SQL in your dashboard") confirms the prior version was exploitable in that posture.
• Untested alerting. Slack is documented as tested only against a faked HTTP client; art references "mail alerts." Alert delivery is the feature most likely to fail silently and the one nobody notices until an incident review.
• Query cost control is unclear from the notes. No mention of statement timeouts, row caps, or cancellation. alerts.rows_in_alert is a threshold for alerting, not a resource limit. Arbitrary user SQL against a replica without a timeout is an availability risk to that replica.

Key questions for the maintainer / vendor

1. Supported Laravel and PHP version matrix, and whether SQLite is supported at all below PHP 8.5 or explicitly degraded.
2. Which DB engines and versions are tested (PostgreSQL major versions, MySQL/MariaDB, SQLite)?
3. Are statement timeouts, max rows, and query cancellation enforced by the package, or left to the DBA (statement_timeout, max_execution_time)?
4. Does execution happen on the request cycle or a queued job? What happens on timeout or worker kill mid-query — are advisory locks guaranteed released by session teardown, or does connection pooling/persistent connections keep them alive?
5. Is every executed statement and check evaluation audit-logged with actor identity?
6. What is the gate/permission model intended to be in production — is there a recommended role/permission set beyond "not local"?
7. Semver/support policy for the 0.1.x line, and disclosure process for future SQL-gate bypasses.
8. What credentials does the dashboard use — the app's default connection, or a dedicated connection you configure? Can it be restricted to a replica?

Integration Approach

Stack fit

• Appropriate only for Laravel applications that already have auth, gates, a scheduler and a queue. It is an internal-operator tool: analysts, support engineers, on-call. It is not appropriate for customer-facing or multi-tenant use where SQL authorship is granted to anyone outside a tightly controlled group.
• Requires a dedicated database connection. Do not point it at the application's primary write connection.

Migration path

1. Sandbox first. Install in a throwaway app against a disposable database, on the oldest PHP/Laravel combination you intend to support. Exercise the quoted/bracketed/schema-qualified/U&"..." bypass cases from the 0.1.1 notes to confirm the fix behaves as documented in your environment.
2. Design the role before the rollout, not after. PostgreSQL: non-superuser, no membership in pg_read_server_files/pg_write_server_files/pg_execute_server_program/pg_signal_backend, REVOKE EXECUTE ON FUNCTION dblink(...), no foreign servers, default_transaction_read_only = on, statement_timeout set. MySQL: no PROCESS, FILE, SUPER, RELOAD, no SELECT ... INTO OUTFILE reachable path, max_execution_time set. Point the connection at a read replica.
3. Replace the gate. Define an explicit permission or role check (e.g. a viewSqlDashboard gate bound to a named internal role), and a stricter separate gate for edit. Leave app()->environment('local') in place as a fallback only.
4. Staging against a production-shaped replica, with the real role, real network path, and the scheduler running.
5. Pilot with a small trusted group, alerts going to mail only. Enable Slack only after you have independently verified delivery against the real Slack API — do not rely on the package's test coverage here.
6. Then consider production, behind your internal SSO/VPN, with an owner and a review cadence.

Compatibility

• Pin the exact version. Given 0.1.x, read the diff of published config and migrations on every bump; re-publish and diff rather than trusting merges.
• SQLite users on PHP < 8.5 should treat read-only enforcement as file-permission-only and plan accordingly.
• Verify the connection check passes for your hardened role — an over-strict check that refuses your legitimate role is a plausible failure mode after a security release, and you want to discover that in staging.

Sequencing Security review → role creation on replica → sandbox validation → gate replacement → staging → pilot → production. Do not compress steps 1–3; the package's safety is not self-contained.

Operational Impact

Maintenance

• Expect a steady stream of security patches on the SQL gate for the foreseeable life of the 0.1.x line. Budget a recurring security review — internal if you have the capability, and at minimum a re-read of the security section plus a bypass-case regression on each release.
• Single-owner risk: this is a niche, early package. Assume self-support. Identify an internal owner (backend engineer) and a backup; a package that runs arbitrary SQL against a replica should not be orphaned.
• Config drift is a real cost — alerts.rows_in_alert became documented only in this release, implying other knobs may be undocumented or renamed.

Support

• Escalation path is the upstream maintainer plus your own DBA. There is no vendor SLA. The internal code review that found 0.1.1's bug is a good sign for responsiveness but also a signal that the gate had a class of defect.
• Slack alerting is explicitly untested against a real endpoint; treat it as a beta feature and own the integration yourself. Mail alerting has the usual deliverability caveats (SPF/DKIM, corporate filters).

Scaling

• The bottleneck is the database, not the package. Arbitrary user SQL is unbounded work: a single careless join on a replica can starve it for everyone else reading from it. Enforce statement_timeout/max_execution_time at the role level, and cap rows returned at the connection or proxy layer if the package does not.
• Check evaluation scales with the number of saved checks × schedule frequency. Each check is a query; put checks on a dedicated queue with concurrency limits, and stagger schedules so they do not align on the minute.
• Advisory-lock/GET_LOCK release matters more as concurrency grows: on a pooled or persistent connection, a leaked lock serialises subsequent sessions. Keep the package on short-lived connections unless you have verified lock release under worker-kill.

Failure modes

• SQL-gate bypass → server-side file read, command execution via COPY ... PROGRAM or dblink/postgres_fdw pivot, or replication/backend-signal abuse. Mitigated primarily by role hardening; the tokenizer is the second line, not the first.
• Misconfigured gate → dashboard reachable by non-operators in a non-local environment. Highest-likelihood, highest-impact operational mistake.
• Alerting silently dead → scheduler not running, queue worker down, untested Slack path, or mail filtered. Checks appear green because nobody is watching the watcher. Add an external dead-man's-switch on "checks evaluated in last N minutes."
• Replica saturation → one heavy query degrades reads for the whole application. Timeouts and a dedicated replica are the controls.
• Lock leakage → a killed worker leaving an advisory lock or GET_LOCK held on a reused connection, stalling later queries.
• Shared-artefact tampering → anyone with the edit gate can change or delete shared queries, dashboards and checks, altering what others see and which alerts fire. Audit and restrict the edit gate.
• Upgrade breakage → a 0.1.x patch changing config keys or migration state during a security-driven emergency upgrade, which is the worst time to debug.

Ramp-up

• Low for a Laravel developer to get a dashboard running (hours); moderate for a team to run it safely (days to weeks), dominated by database role design, replica provisioning, and the security review — not by the package itself.
• On-call needs to know three things: how to revoke access fast (gate + role), how to kill a runaway query on the replica, and how to confirm alerting is alive. Write those down before the pilot, not after.
• Re-evaluate this assessment at 0.2/1.0, on any further SQL-gate security release, or if the gate/role model changes.