mirror of
https://github.com/Dokploy/templates.git
synced 2026-11-11 13:38:07 -06:00
d7b7097fdc
0.18.1 fixes GHSA-jwvh-6phv-j9jh, whose affected range this blueprint was squarely inside: it sets STORAGE_PROVIDER=sqlite, and the advisory covers every release from 0.8.0 through 0.18.0 on a server store. The blueprint also seeds two accounts, admin and user. Where those two go to different people who share a browser profile, that is the shape the defect needs: the second to sign in received the first one's browser copy of the workspace, with its saved connection passwords and its query history. Both passwords come from this template's own generated secrets, so by default the two logins belong to one deployer and nothing crosses a privacy boundary; it is handing USER_PASSWORD to someone else that opens it. 0.18.2 then adds a run of fixes across the PostgreSQL family, the wire-compatible engines, MySQL, MongoDB, Redis and Oracle. meta.json also said twenty-six drivers. Databend became a connection type of its own in 0.18.1, where it had been reached as a relative of the MySQL type, so the count is twenty-seven. The fifty-four named engines are unchanged, because Databend only moved from one side of that sum to the other. One line is added beside the bump, because testing the upgrade turned up a lockout the blueprint could not recover from. Since 0.18.0 ADMIN_PASSWORD seeds the account table only while it is empty, so an operator who edits it in Dokploy's Environment panel gets 401 on the new password while the old one, which the panel no longer shows, still works. The app logs the way out, "set ADMIN_PASSWORD_RESET=true and restart", but the compose environment list is an allowlist: typing that variable into the same panel never reached the container, so the advice could not be followed without editing the blueprint itself. ADMIN_PASSWORD_RESET is now passed through with an empty default. Measured on 0.18.2 with this file: empty leaves the container with the variable defined and blank, both accounts sign in normally and neither reset line appears in the log; with it set to true the new password returns 200 and the old one 401; with the flag removed again the new password keeps working. There is no USER equivalent in the application, which the comment says, so that account is changed from Studio's own Accounts screen. Co-authored-by: yusuf-gundogdu <devgundogdu86@gmail.com>
