Jmal-cloud-view: the front end that documents its own admin password reset

The password reset procedure ends by telling you the password

The README has a section for resetting the administrator password, and it is a shell command against the database container rather than a UI action:

# 1. 重置密码
docker exec -it jmalcloud_mongodb mongo jmalcloud --eval "db.getCollection('user').update({ 'creator': true }, {\$set: { 'password': '1000:c5b705ea13a1221f5e59110947ed806f8a978e955fbd2ed6:22508de12228c34a235454a0caf3bcaa5552858543258e56' }}, { 'multi': false, 'upsert': false })"
# 2. 重启容器
docker restart jmalcloud_server
# 重置后的密码为: jmalcloud

It writes a fixed hash into the password field of the single user flagged as creator, and both upsert and multi are false, so nothing is created and only that one account changes. The server container is then restarted and the next line states the resulting password in plain text.

Nothing here is a vulnerability in itself. It is a documented recovery path, and having one is better than having none. But the consequence is that the administrator credential of a default deployment is public, so the first thing to do after docker compose up is change it.

The same section also shows the backup and restore pair, a mongodump into a dump path with gzip and a matching mongorestore filtered to the jmalcloud namespace.

Four environment files and two test directories are committed

The top level of the repository is worth reading as a configuration inventory. It holds .editorconfig, .env, .env.development, .env.production and .env.test, then .github/, .gitignore, a Dockerfile, both README.md and README_en_US.md, babel.config.js, a build/ directory, config.js.template, doc/, docker-entrypoint.sh, docker/, jest.config.js, jsconfig.json, nginx/, package.json, postcss.config.js, prettier.config.js, public/, railway.yaml, src/, test/, tests/ and vue.config.js.

Four environment files are tracked, which in a project with a .gitignore means the build configuration, including the production one, is visible to anyone who clones it.

There are also two test directories, test/ and tests/, side by side. A jest config exists, so at least one of them is wired into the runner, and the README says nothing about which.

railway.yaml is the one entry with no explanation anywhere: it is a deployment descriptor for a hosted platform, and the documented deployment path is Docker Compose. config.js.template is the runtime configuration the image copies next to the built assets, which is how one image can be pointed at different servers.

Four interface stacks in a single dependency list

The dependency list explains the age and the shape of the interface. It starts with pinned versions for the document viewers, @vue-office/docx at 1.6.2 and @vue-office/excel at 1.7.11, and @vue/composition-api at 1.7.2, so this is a Vue 2 application with the compatibility layer rather than Vue 3.

Then three component systems appear in a row: ant-design-vue at 1.6.5, element-theme-darkplus at 2.1.4, and the Vue Office packages. Underneath them sit jquery at 3.5.0 with jquery-contextmenu and jquery.fancytree, both jQuery plugins used for tree and menu behaviour that a Vue tree component would normally handle.

Editing comes in two flavours too: monaco-editor at 0.30.1 with its Vue wrapper, its webpack plugin and monaco-languages, and separately htmlhint and jshint, which are linters and have no business being runtime dependencies.

The list also carries three ^0.182.0, the WebGL library, in a file manager, and streamsaver, spark-md5, flv.js, hls.js, stompjs and sockjs-client for downloads, chunk hashing, video playback and sockets.

The dev script switches on the OpenSSL legacy provider

The dev entry in the manifest is not a plain vue-cli-service call:

npm run dev

The underlying command is NODE_OPTIONS=--openssl-legacy-provider vue-cli-service serve, so the build tooling is old enough that it needs the legacy OpenSSL provider flag to run on a modern Node.

The README's own prerequisites agree about the vintage. Development needs jdk17+, mongodb4.4+ and node v16.x.x, and the four steps it gives are to clone the server repository, edit src/main/resources/file.yml to point rootDir and ip2region-db-path at real directories, clone this web project, and then npm install followed by npm run dev.

The test scripts follow the same pattern. test:unit clears the jest cache and then hands over to vue-cli-service test:unit, and test:ci is lint followed by test:unit, where lint is eslint over .js and .vue files in src. There is a separate svgo script pointed at src/icons/svg with its own config.

Nothing here is broken, but every entry point is a wrapper around a Vue CLI toolchain, which is the part a maintainer inherits.

The image exposes 80, the documentation says 7070

The Dockerfile starts from somebody else's image:

FROM jmal/nginx-drawio:latest

Everything in the web tier is built on top of that one tag. It is a personal namespace rather than an official base image, it is pinned to latest, and it bundles nginx together with draw.io, which is where the flowchart and diagram editing comes from.

From there the file adds gettext, copies two nginx configuration templates, one of them a no_office variant, plus two proxy parameter files, copies the built dist into /var/www/public, drops config.js.template beside it, installs the entrypoint script as executable, exposes 80, and starts nginx.

The gettext install is the tell for why there are two templates: the entrypoint substitutes configuration at container start, which is how one image serves different environments. The port mismatch is the other thing to notice. The image exposes 80 and the README tells you to open http://{your_ip}:7070, so the translation happens in the compose file, which lives in the server repository rather than here.

The deploy instructions link to another repository's compose file

The deployment section asks for Docker and Docker Compose v2.0+, then points at docker-compose.yml hosted in jamebal/jmal-cloud-server, not in this repository. The command itself is one line:

docker compose up -d

That makes the split explicit: this repository is the web front end, and the server, the database and the object storage wiring live next door. The README is a little coy about it, describing the whole product as a private cloud drive project without saying which half you have cloned.

There is also a hosted demo, at jmal.cc/demo, with the username demo and the password demo1234 printed in the text. A public demo account is normal, but it does mean anyone evaluating the interface is looking at the same shared data unless the demo resets.

The feature list is what this repository is actually about: OSS, Aliyun OS, Tencent Cloud OSS and MinIO as backends, online preview for images, audio and video, editing and preview for Word, Excel, PowerPoint, flowcharts and mind maps, WebDAV, and resumable uploads for very large files, on x86 and arm64 across CentOS, Debian, Ubuntu and macOS.

An empty screenshots section, and a browser table that still lists Internet Explorer

Two headings in the README have nothing under them. The screenshots section is a title followed by no images, so the interface has to be judged from the hosted demo instead.

The browser support table is the other one. It lists IE10, IE11 and Edge in the first column, then the last two versions of Firefox, Chrome and Safari in the other three.

That table is the clearest statement of the project's compatibility posture, and it is expensive to keep. The Vue 2 dependency set, the legacy OpenSSL flag, the ant-design-vue 1.x pin and the jQuery plugins all line up with a codebase that still has to run in an Internet Explorer era browser, and every one of those choices is a constraint on the next upgrade rather than a detail.

The licensing is the plainest thing here: MIT, with copyright attributed to jmal from 2020 onwards. The default branch is master rather than main, and the most recent release, v2.16.9, was published on the same minute as the last push to it.

Editorial conclusion

Jmal-cloud-view is the front end of a two-repository product, so reading it tells you what the interface is made of rather than how the storage works. It is worth deploying for a private drive, with three conditions: change the administrator password the README hands you on first boot, pin the base image instead of tracking its latest tag, and remember that the compose file and the server code live in the other repository. Anyone extending it will spend their first hour untangling the four UI stacks already in the dependency list.

Frequently asked questions

Official sources

1. jamebal/jmal-cloud-view on GitHub
2. License: MIT
3. Project website
4. README
5. Releases