Skip to content

Blank Quartz's placeholder H2 admin/admin datasource credential - #3207

Open
terryozaki-wq wants to merge 1 commit into
devfrom
quartz-blank-placeholder-credential
Open

terryozaki-wq wants to merge 1 commit into
devfrom
quartz-blank-placeholder-credential

Conversation

@terryozaki-wq

Copy link
Copy Markdown

Summary

  • quartz.properties shipped with a real-looking hardcoded H2 datasource credential (user=admin, password=admin, URL pointing at a developer's own Windows machine path), despite SchedulerFactorySingleton.init() always routing through setUpQuartzProperties(), which unconditionally overwrites driver/URL/user/password with the actual scheduler database's own connection details before Quartz's StdSchedulerFactory is ever initialized — confirmed by direct trace of both call sites in init() and the single setUpQuartzProperties() implementation they share.
  • This fails open rather than closed: Quartz would simply run with the weak default silently if the override logic were ever changed to skip it. Blanking the four placeholder values instead means a future regression in the override logic surfaces as an obvious connection failure rather than a silent weak default.

Test plan

  • New SchedulerFactorySingletonUnitTests, using the real project quartz.properties copied into the test's base folder exactly as semosshome.xml packages it for deployment: confirms the four placeholders are blank (not admin) in the file itself, setUpQuartzProperties() correctly overwrites all four with real connection details regardless, and non-connection settings (jobStore.class, tablePrefix) still load from the file as before — 3/3 passing.

🤖 Generated with Claude Code

…redential

quartz.properties shipped with a real-looking hardcoded H2 datasource
credential (user=admin, password=admin, URL pointing at a developer's
own Windows machine path), despite SchedulerFactorySingleton.init()
always routing through setUpQuartzProperties(), which unconditionally
overwrites driver/URL/user/password with the actual scheduler
database's own connection details before Quartz's StdSchedulerFactory
is ever initialized - confirmed by direct trace of both call sites in
init() (the IEmbeddedRDBMSServerEngine and RDBMSNativeEngine branches)
and the single setUpQuartzProperties() implementation they share.

This fails open rather than closed: Quartz would simply run with the
weak default silently if the override logic were ever changed to skip
it, since there's no equivalent of a fail-closed ConfigurationException.
Blanking the four placeholder values instead means a future regression
in the override logic would surface as an obvious connection failure.

Added SchedulerFactorySingletonUnitTests to confirm, using the real
project quartz.properties copied into the test's base folder exactly
as semosshome.xml packages it for deployment: the four placeholders are
blank (not "admin") in the file itself, setUpQuartzProperties()
correctly overwrites all four with real connection details regardless,
and the non-connection settings (jobStore.class, tablePrefix) still
load from the file as before.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@terryozaki-wq
terryozaki-wq requested a review from a team as a code owner October 26, 2026 16:43
@snyk-io

snyk-io Bot commented Oct 26, 2026

Copy link
Copy Markdown
Contributor

✅ Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
✅ Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant