The console application was created with a hand-written list of eight
constructor arguments, which broke whenever Nextcloud changed its
constructor. Resolve the arguments by type from the container instead,
passing our own request so the console still gets an argv for its
ConsoleEvent.
Only admins can use the app, so who gets admin rights decides who can use
it. The database should run as a scoped user without superuser or
server file/program rights, since the SQL checks are an extra layer.
Explain why sensitive occ commands are not blocked: an admin can reach
the same information in other ways, so a blocklist would only give a
false sense of security and make the app less useful.
SET PASSWORD, SET GLOBAL and SET PERSIST (also as @@GLOBAL.x) change
the server or the database account rather than the session, so they
need confirmation like other writes. Session variables stay a read.
SHOW, EXPLAIN, VALUES and TABLE count as reads now but their rows were
dropped and reported as a write; every read except SET now returns its
rows. nextval() advances a sequence, so it needs confirmation like
setval().
removeComments() used regexes that also matched "--" and "/*" inside
string literals. A literal like '--' or '/*' then removed the code after
it from the checks while PostgreSQL still ran it, e.g.
COPY (SELECT '--') TO PROGRAM 'sh' passed the forbidden-construct check,
and a DELETE in a CTE between '/*' and '*/' literals skipped the
confirmation.
Comments and literals are now found by one scanner that walks the SQL
the way the database does ('...', E'...', "...", $tag$...$tag$, -- and
block comments), shared by removeComments(), removeLiterals() and
splitStatements().
splitStatements() only knew 'strings' and "identifiers", so a DO block
or function body ($$ ... ; ... $$) was cut at its inner semicolons and
failed, and a quote inside a comment (-- don't) opened a string that
never closed. It now also skips dollar-quoted bodies, E'...' strings
with backslash escapes, and comments. It moves to SqlGuard so it is
tested with the other checks.
OccController::run() now catches Throwable, so an Error thrown by a
command is logged and returned like an Exception instead of ending in
an HTTP 500.
Not changed on purpose: showing rows for statements with RETURNING or
data-modifying CTEs, and failure handling in the Makefile release
targets. Both came up in the same review but are unrelated to the
security fixes in this release.
A security review found three issues:
- Comments were removed without a space before matching the forbidden
patterns, so "TO/**/PROGRAM" became "TOPROGRAM" and passed the
COPY ... PROGRAM check while PostgreSQL still ran it. Comments are
now replaced by a space, and the COPY file check also covers E'...',
U&'...' and dollar-quoted file names.
- Only statements starting with DELETE or UPDATE asked for
confirmation, so a leading block comment, a data-modifying CTE
(WITH x AS (DELETE ...)) or DROP/TRUNCATE/INSERT ran without it.
Every statement that is not a plain read now needs confirmation,
decided on the server.
- occ output could contain escape sequences, backspaces and URLs from
user-controlled text (display names, file names) that rewrite or hide
text or show a clickable link. Only color codes are kept now, and
URLs are no longer turned into links.
The checks move to SqlGuard so they can be tested on their own. They
remain defense in depth: dynamic SQL can always get around a text
check, so the database role should not have superuser rights,
pg_execute_server_program or pg_read/write_server_files. A read that
starts with WITH now shows its rows like a SELECT.
The overtyping and from_ansi formatters unescape brackets before they
parse the text, so escaping them beforehand was not enough: literal
brackets were still read as formatting. Enable
unixFormattingEscapeBrackets so both formatters escape the text again
after parsing. Verified in the browser: Symfony's "[alias]" in
`occ list` stays in place, ANSI colors still work, and formatting in
the output text (colors, links) is no longer applied.
Bump the version to 0.4.4 so browsers load the new script.
jQuery Terminal reads "[" and "]" as its own formatting syntax. occ
output was echoed as is, so literal brackets, such as Symfony's
"[alias]" in `occ list`, closed the color formatting of the next line
early and moved text to the wrong place. Text from the output, like a
display name, could also inject terminal formatting.
Escape the brackets in the text and keep the ANSI sequences, so the
colors still work.
git archive HEAD packages whatever commit the checkout currently points to,
regardless of branch - check-clean-tree only guards uncommitted changes, not
HEAD being a feature branch, old tag, PR checkout, or detached HEAD entirely.
Wired into source/appstore/version alongside the existing guards.
Override via RELEASE_BRANCH=<branch> for an intentional non-main release.
Core still provides a working jQuery on NC32/33, but via a read-only
window.$ getter - loading our own vendored copy there too made its UMD
wrapper throw trying to reassign window.$ (confirmed on real containers,
harmless in practice since this app attaches via window.jQuery, but a real
avoidable console exception). Gate the extra script() call on
ServerVersion::getMajorVersion() >= 34 instead.
Re-tested both sides of the boundary: NC32 no longer requests jquery.js and
has zero console errors; NC34 still requests it and still works.
testbak/ (local, non-AIO docker compat rigs for NC32/33/34/35) found a real
fatal on NC35: OccOutput::setErrorOutput() didn't declare the ": void"
return type the Symfony Console version NC35 bundles now requires on
ConsoleOutputInterface. Fixed by declaring it - compatible with older
Symfony/NC versions too since it only narrows an untyped parent signature.
32/33 were also verified functional (the previously-suspected jQuery
getter-conflict console exception on those versions is real but harmless -
the app attaches via window.jQuery, not window.$).
min-version/max-version narrowed from 30/34 to 32/35: 30/31 were never
actually tested even before this session, so keeping them was an unverified
claim; 35 is now genuinely verified rather than guessed.
Running make appstore/source/dist directly (bypassing make version)
still had the stale-archive risk check-clean-tree was added for:
app_name/paths read from a dirty working tree while git archive HEAD
packages the last commit. Added check-clean-tree as a prerequisite to
source and appstore directly, not just transitively through version.
app_name now comes from xpath against appinfo/info.xml (needed so
packaging works regardless of what this checkout is named - see the
git-archive fix). If xpath isn't installed, $(shell ...) just returns
an empty string rather than failing the build: --prefix=$(app_name)/
would silently become --prefix=/, producing a broken, wrongly-rooted
archive with no indication anything went wrong. Previously app_name
came from the checkout directory name, so this failure mode didn't
exist. Added a check-app-name prerequisite to source/appstore/sign
that fails loudly if app_name is empty.
VERSION/app_name are read live from the working tree's info.xml, but
the packaged/signed content comes from git archive HEAD (the last
commit). Bumping <version> without committing first would tag and
sign an artifact named/keyed after the new version while its actual
contents are still the previous commit's. make version now refuses to
proceed if there are any uncommitted changes to tracked files.
git push fork v\$(VERSION) only works on this maintainer's own machine,
where "fork" happens to be configured (and where "origin" still means
the stale upstream, from how this repo was originally forked). A plain
clone via the README's own instructions only ever creates "origin",
pointing at dillardblom/occweb - so make version would tag locally,
then fail at the push step before packaging/signing ever ran.
Made the target remote configurable via RELEASE_REMOTE, defaulting to
"origin" (correct for a normal clone), overridable for this specific
checkout's non-standard remote layout.
The ensure-app-name-symlink fix from the previous commit created
../extended_occweb as a symlink so the inherited "../$(app_name)" tar
references would resolve regardless of the checkout's real directory
name - but the tar invocations ran without --dereference, so GNU tar
stored the symlink itself rather than following it into the real
files. make source/appstore therefore produced a 1-entry archive
containing nothing but a dangling absolute symlink, unusable on any
other machine. Caught by a second independent Codex pass; my own
"make appstore" test after the first fix only checked the archive's
top-level entry name, not its actual file count, so this went
unnoticed.
Rather than patch this with --dereference, replaced the whole
symlink+raw-tar approach with `git archive --prefix=$(app_name)/
HEAD`: it sets the correct top-level folder name directly (no symlink
needed at all), and - caught during this fix's own verification,
not by either Codex pass - it also closes a separate real leak the
symlink approach had: tarring the checkout directory directly
included every untracked/gitignored file too (e.g.
notes/deploy-nc01.md, which exists specifically because it must
never leave this machine). `git archive` only ever includes tracked
files. Dev/CI-only files (tests/, Makefile, composer.*, phpunit*.xml,
.travis.yml) are now stripped via `export-ignore` entries in a new
.gitattributes instead of a long list of tar --exclude flags repeated
per target - also means source and appstore now produce identical
output, which is fine given neither is part of our actual release
flow yet.
Verified end to end this time: extracted the resulting archive and
confirmed file count, absence of symlinks, absence of tests/notes/
dev files, and correct info.xml content - not just the archive's
top-level listing.
Independent Codex review of the app-id rename found real gaps our own
review missed:
- Makefile: app_name was derived from the checkout directory's own
basename, not the app id in appinfo/info.xml. Our actual working
checkout is still named "occweb" (matches the repo name), so
building from it would have produced an "occweb"-named/rooted
archive under the new "extended_occweb" id. Fixed by deriving
app_name from info.xml via xpath (same technique already used for
VERSION), and added an ensure-app-name-symlink step so the
Makefile's inherited "../$(app_name)" references (used throughout
the source/appstore tar exclude patterns) keep resolving correctly
regardless of what the checkout directory is actually named.
Verified end to end: `make appstore` now produces
extended_occweb.tar.gz with extended_occweb/ as its single top-level
folder, matching the App Store's stated requirement.
- Makefile: sign target had "occweb" hardcoded into both the
certificate path and the archive filename - broken independent of
the app_name fix above. Now derived from the same variables.
- Makefile: version target pushed the release tag to the "origin"
remote, which in this repo is the stale upstream
(fanategorius/occweb), not somewhere we want to push. Changed to
"fork" (dillardblom/occweb), matching how every tag has actually
been pushed this whole session.
- INSTALL-AIO.md / notes/deploy-nc01.md: the deploy snippet did
`git archive main` unconditionally, silently deploying the main
branch even if an operator had checked out a specific tag or
maintenance branch as instructed elsewhere. Changed to `git archive
HEAD`.
- README.md: the compatibility matrix's rollback advice
("git checkout v0.3.4") doesn't actually work as a rollback anymore
post-rename - that tag still declares the old occweb id, so checking
it out under an extended_occweb-named install just breaks. Added a
caveat explaining what a real rollback requires; full migration docs
are still deferred to when a test instance exists (tracked
separately, not written up here).
- js/index.js: the occ-command ajax call used the wrong jQuery .fail()
signature ((response, code) instead of (jqXHR, textStatus,
errorThrown)), so any failure printed the literal string
"[object Object]" instead of a useful message.
- js/index.js: the initial bootstrap call that builds the terminal had
no .fail() handler at all - a failure there (expired session/CSRF
token, network error, rejected admin check) left #app-content
permanently blank with zero diagnostic information. This is exactly
what made today's NC34 debugging session harder than it needed to
be; now it shows the actual HTTP status/reason in the page.
- OccController.php: translated a leftover Dutch comment (missed by
the earlier Russian->English pass since it wasn't Russian), and
documented why requireAdmin() is intentional defense-in-depth rather
than a misunderstanding of the framework: verified against
Nextcloud's own SecurityMiddleware source that any controller method
without @NoAdminRequired already rejects non-admins by default, so
this check (and the original "security fix" commit that added it)
was addressing a non-issue for THIS controller specifically.
DbController's equivalent check is still genuinely load-bearing -
that controller originally shipped with @PublicPage, which does
bypass the default protection - so it gets a note explaining the
distinction instead.
- README: added compatibility matrix rows for 0.4.0 (app id rename to
extended_occweb) and 0.4.1 (these fixes), both verified on NC 34.0.4.
Deferred to when a test instance exists (tracked, not fixed here): no
documented migration path from the old occweb id to extended_occweb
for existing installs, OccController's constructor doing expensive
work before the (redundant) admin check runs, and js/jquery.js loading
unconditionally on NC30-33 where core still provides jQuery.
Version bump to 0.4.1.
Nextcloud's app id "occweb" is effectively unavailable for a new store
listing: the original Adphi/occweb still owns that App Store slot
(stale, v0.2.3), and el-choco/occweb_v2 has since published a
same-lineage rewrite under its own id. Rather than fight over the
"occweb" name, publish this fork under its own id, matching the
<name> this app has always had: "Extended OCC Web".
Renames every place the literal app id is used: info.xml <id> and the
auto-generated navigation <route>, script()/style() registrations in
templates/index.php, the TemplateResponse app name in
OccController::index(), the /apps/... base URL in js/index.js, and the
'app' log context tag in DbController.php. The GitHub repo name and
its <website>/<bugs>/<repository>/<screenshot> links are unaffected -
those identify the repo, not the Nextcloud app.
Docs (README, INSTALL-AIO.md, install.sh) updated to clone into and
reference an "extended_occweb" directory, since Nextcloud requires the
app folder name to match its id - a plain `git clone` of this repo no
longer produces a correctly-named install directory on its own.
Version bump to 0.4.0 given the scope (breaking change for anyone who
already deployed under the old "occweb" id - requires disable+remove
of the old app and a fresh enable under the new id, not an in-place
upgrade).
Live-tested against nc01 after its auto-update jumped to NC 34.0.4:
- Nextcloud's global jQuery has been deprecated since NC19 and is no
longer reliably present/first-loaded on NC34 (other apps like
serverinfo hit the same issue). occweb's index.js and the vendored
jquery.terminal (term.js) both assume a global jQuery, so ship our
own copy (js/jquery.js, 3.7.1 from code.jquery.com) and load it
before them in templates/index.php. Fixes a hard "jQuery is not
defined" crash that left the terminal blank (black screen).
- With that fixed, every ajax call started failing with HTTP 412
"CSRF check failed": core only auto-attaches the requesttoken
header to requests made through ITS OWN globally-loaded jQuery, and
with occweb now vendoring a separate jQuery instance that no longer
happens. A global $.ajaxSetup() call turned out unreliable (another
app's later jQuery load can replace window.jQuery afterwards), so
each of the three ajax calls (SQL query, initial completion list,
occ command execution) now sets the requesttoken header explicitly
via OC.requestToken.
Bump max-version to 34 - actually verified working on NC 34.0.4 now,
not inherited/guessed (see the policy comment in this same file).
Version bump to 0.3.5.
The previous version was in Dutch and hardcoded internal deploy details
(hostname alias, personal local path, private Gitea mirror domain) that
had no business being in a public repo. Replaced with a generic version
using <docker-host> placeholders; the internal nc01-specific copy now
lives at notes/deploy-nc01.md, which is gitignored and stays local-only.
Not rewriting prior history for this (confirmed with user: nothing
credential-level was exposed, just a hostname alias and a path).
35 was fanategorius's own tested value, but this is now a modified
fork (CSRF fix, admin checks, translated internals) - inheriting their
compatibility claim isn't the same as having verified it ourselves.
33 is the only version this fork has actually run on (nc01).
An untested max-version that's too high is worse than one that's
accurate: on the next core bump, Nextcloud's own compat check would
keep the app enabled on an unverified major instead of cleanly
disabling it, so a real incompatibility would surface as a runtime
error instead of a safe, expected "needs testing" disable.
Policy going forward (documented inline in info.xml): test against
the next major's beta ahead of time and bump max-version before that
major goes final, so the app is never caught by surprise - never bump
it reactively/speculatively.
README.md and install.sh's install instructions still told new users to
git clone the abandoned upstream (fanategorius/occweb), which lacks all
of this fork's fixes. Point those at dillardblom/occweb; leave the
Credits section's links to Adphi/fanategorius as-is since those are
deliberate attribution, not install instructions. Also repoint the
README screenshot badge, which was hotlinking Adphi's repo.
composer.json still listed only the original author; add ourselves
alongside, matching the info.xml author field.
Revert max-version 40->35: 35 was fanategorius's own tested release
value (commit 7c09dd2), not a guess. Bumping to 40 was our own
speculative headroom into an untested future major - exactly the
pattern this project's own history already reverted twice, for the
same stated reason ("hasn't been tested against newer Nextcloud
releases"). Getting auto-disabled by the compat check on an untested
major is the correct, safe failure mode; claiming compatibility we
haven't verified is not. 35 still satisfies the Codex finding (no
narrowing below a previously-validated ceiling) without guessing ahead.
Codex review flagged the previous 35->33 change as an unjustified
compatibility regression: nothing in this app's code is actually
incompatible with NC 34/35, so narrowing the ceiling only reflects
nc01's current version, not a real limitation. Worse, nc01's AIO now
auto-updates its core nightly (watchtower-aio), so pinning max-version
to today's exact version would very likely repeat the 2026-08-09
incident (occweb auto-disabled by the compat check) on the very next
core bump. This app only calls a handful of stable, long-lived OCP
interfaces, so a generous ceiling carries little real compatibility
risk compared to that recurring outage.
Was untracked locally and stale (referenced apps/ instead of custom_apps/,
git clone inside the container instead of our tar-based deploy). Documents
the two things that just caused a production incident on nc01: files
extracted from a tarball keep the source uid/gid and need an explicit
chown to www-data, and skipping the installed_version sync after bumping
<version> puts the whole instance in "needs upgrade" state, which blocks
not just occ commands but the web login page too.
Link it from README.md's install section.
occ status on nc01 reports 33.0.8.2, not 36 as assumed — match the
repo's established convention of pinning max-version to the actually
tested/installed core version rather than a guess.
query() runs arbitrary admin SQL (including DELETE/UPDATE) and was
exempted from CSRF protection — a leftover from the original upstream
code, which had this alongside @PublicPage (no auth at all) before our
admin-check hardening. The client already goes through the standard
$.ajax() flow that auto-attaches Nextcloud's CSRF token, exactly like
OccController::cmd() does without any such exemption, so removing it
has no functional cost.
Also bump nextcloud max-version to 36 to match nc01's current core
version, now that AIO auto-updates the core nightly.
Version bump to 0.3.4.
Covers OccOutput.php, DbController.php and js/index.js: docblocks,
inline comments, the forbidden-construct labels shown to admins in
error responses, and the SQL template descriptions shown in the
terminal (delete-user, list-user, rename-user).
Also backport OccController's getConfig() -> IConfig::class fix (deprecated
internal API -> stable OCP interface), spotted while comparing against
Git-Usr123/occweb.
index(), cmd() and list() were accessible to any logged-in user.
The navigation menu already restricts visibility to admins, but the
routes themselves were unprotected — any authenticated user who knows
the URL could execute occ commands or list all available commands.
Fix: inject IGroupManager + IUserSession, add requireAdmin() helper,
call it at the start of all three public methods. Matches the pattern
already used in DbController.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
BufferedOutput::fetch() declares a string return type in Symfony 5+.
PHP 8.1 enforces return type compatibility with parent methods, causing
a fatal 500 error when the occweb page loads.
Fix: add ': string' return type to OccOutput::fetch().
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- New 'rename-user' template (templates / template rename-user <old> <new>):
best-effort uid rename across core tables (oc_users, oc_preferences,
oc_group_user, oc_group_admin, oc_ldap_user_mapping, oc_share, oc_mounts,
oc_storages). Explicitly NOT a supported Nextcloud operation - the
generated script carries an in-line warning (as leading SQL comments)
that app-specific tables (Talk, Calendar, Contacts, Mail, 2FA/WebAuthn...)
are not covered and that the data directory must be renamed on disk
manually, followed by occ files:scan --all. Documented the same caveat
in both READMEs.
- Hardened the round-2 transaction wrapping: beginTransaction()/commit()/
rollBack() are now wrapped in try/catch. PostgreSQL (our backend) has
fully transactional DDL so this wasn't actually broken here, but
Nextcloud also supports MySQL/MariaDB via the same IDBConnection, where
DDL implicitly commits - on that backend a DDL statement in the batch
would make a later commit()/rollBack() throw 'no active transaction'
and previously that exception was unhandled (HTTP 500 instead of a
clean JSON response). Now: if rollBack() itself fails after an error,
we report rollbackFailed+warning instead of falsely claiming rolledBack,
since earlier statements in that batch may already be permanently
applied. If commit() fails with nothing to commit (already
auto-committed), that's logged only, since the effects are already
durably persisted.
- removeAllComments() strips -- and /* */ comments before checking
FORBIDDEN_PATTERNS, closing a bypass where a comment inserted between
a function name and '(' hid it from the regex (e.g. pg_read_file/**/(...)).
- UPDATE now requires confirm=true just like DELETE (deleteCount/updateCount).
- Batches run inside a single DB transaction; a failing statement rolls back
everything already applied in that batch instead of leaving partial writes.
- splitStatements() (PHP and JS) now tracks a single quoteChar instead of a
bool, handling both '...' strings and "..." quoted identifiers symmetrically.
- Frontend TEMPLATES no longer rely on SET/current_setting: the escaped uid
is inlined into every statement, so partial copy/paste still works.
- renderTable() renders NULL as [NULL] instead of an empty string, so it's
no longer visually identical to an empty string value.
- Added MAX_SQL_BYTES (1MB) request size limit, returned as HTTP 413.
- Added a 120s client-side AJAX timeout with a distinct timeout message,
so a hung request doesn't leave the terminal paused indefinitely.
dillard
Egor Bugaev