951737d7d0
it'd previously always try to parse as multipart first now it'll immediately assume the upload post api is for url uploads if the request type is json |
||
---|---|---|
.github/workflows | ||
controllers | ||
dist | ||
docker | ||
pages | ||
public | ||
routes | ||
scripts | ||
src | ||
views | ||
.browserslistrc | ||
.dockerignore | ||
.editorconfig | ||
.eslintignore | ||
.eslintrc.js | ||
.gitignore | ||
.stylelintignore | ||
.stylelintrc.json | ||
AUTHORS | ||
config.sample.js | ||
gulpfile.js | ||
LICENSE | ||
logger.js | ||
lolisafe.js | ||
package.json | ||
README.md | ||
renovate.json | ||
yarn.lock |
lolisafe, a small safe worth protecting
Features
- Powered by uWebSockets.js & HyperExpress for a much more performant web server, due to being a Node.js binding of uWebSockets written in C & C++.
- Powered by better-sqlite3 for performant SQLite3 database (using Knex.js for abstraction, thus support for other database engines may also come in the future).
- Faster file hashing for duplicates detection by using BLAKE3 hash function, powered by blake3 Node.js library.
- ClamAV virus scanning support for Linux/OS X servers (read more).
- Front-end pages templating with Nunjucks.
- A more integrated Cloudflare support (automatically purge files remote cache upon deletion, and more).
- Chunked uploads to support 100MB+ files when hosted behind Cloudflare, or any other proxies with file upload size limits.
- Upload remote URLs (have the service download those remote files for you).
- Performant rate limits powered by rate-limiter-flexible.
- Albums with shareable pretty public pages.
- User dashboard to manage own uploads and albums.
- Admin dashboard to manage all uploads, albums, and users.
- Robust files search/filters and sorting in the dashboard.
- Usergroups-based permissions.
- Configurable file retention periods per-usergroups.
- Strip images EXIF tags if required (can be set to be toggleable by users, and with experimental support for stripping videos tags as well).
- Various options configurable via header tags upon file uploads (selected file retention period, whether to strip EXIF tags, and more).
- ShareX support with config file builder in the homepage.
- Token-based authentication on all APIs, allowing you to easily integrate the service with anything.
- ... and more!
Differences with Upstream/Chibisafe
This fork is the one being used at https://safe.fiery.me.
It was originally based on WeebDev/lolisafe v3, but later have been so heavily rewritten that it is now simply its own thing.
Chibisafe is an upstream rewrite & rebrand, and technically is lolisafe v4.
If you want to use an existing lolisafe v3 database with this fork, copy over database/db
file from your previous installation, then run yarn migrate
at least once to create the new database columns introduced in this fork (don't forget to make a backup).
Said migration script is NOT COMPATIBLE with Chibisafe's database.
Configuration file of lolisafe v3 (config.js
) is also NOT fully compatible with this fork. There are some options that had been renamed and/or restructured. Please make sure your config matches the sample in config.sample.js
before starting and/or migrating your previous database.
Running in production mode
- Ensure you have at least Node v14 installed (fully compatible up to Node v16.x LTS, untested with v17 or later).
- Clone this repo.
- Copy
config.sample.js
asconfig.js
. - Modify port, domain and privacy options if desired.
- Run
yarn install --production
to install all production dependencies (Yes, use yarn). - Run
yarn start
to start the service.
Default admin account:
Username:root
Password:changeme
You can also start it with yarn pm2
if you have PM2.
When running in production mode, the safe will use pre-built client-side CSS/JS files from dist
directory, while the actual source codes are in src
directory.
The pre-built files are processed with postcss-preset-env, cssnano, bublé, and terser, and done automatically with GitHub Actions.
If you want to use this on Docker, please check out docker directory.
Running in development mode
This fork has a separate development mode, with which client-side CSS/JS files in src
directory will be automatically rebuilt using Gulp tasks.
- Follow step 1 to 4 from the production instructions above.
- Run
yarn install
to install all dependencies, including development ones. - Run
yarn develop
to start the service in development mode.
You can configure the Gulp tasks through gulpfile.js
file.
During development, the rebuilt files will be saved in dist-dev
directory instead of dist
directory. The service will also automatically serve the files from dist-dev
directory instead. This is to avoid your IDE's Git from unnecessarily rebuilding diff of the modified files.
Once you feel like your modifications are ready for production usage, you can then run yarn build
to build production-ready files that will actually go to dist
directory.
If you are submitting a Pull Request, please do not stage any changes to files in
dist
directory.
GitHub Actions will automatically rebuild those assets if and when required.
Updating when you have modified some files
Try to use git stash.
Basically you'll be doing this:
git stash
to stash away your changes.git pull
to pull updates.yarn install
(oryarn install --production
) to install dependencies matching the updatedyarn.lock
file.git stash pop
(orgit stash apply
) to restore your changes.
Be warned that some files may have been updated too heavily that they will require manual merging.
If you only do some small modifications such as editing .njk
files and not much else, it's generally safe to do this even in a live production environment. But it's still best practice to at least review just what have been updated, and whether you will need to do some manual merging beforehand.
Still, I heavily recommend simply forking this repository and manually merging upstream changes whenever you feel like doing so. Read more about syncing a fork. Especially if you intend to modify client-side CSS/JS files in src
directory, since you will then need to rebuild assets that go into dist
directory, which are guaranteed to always conflict with every updates from this fork that modify them.
Afterwards, you can instead clone your fork into your production server and pull updates from there. You can then choose to only install production dependencies with yarn install --production
there to save some disk space (hint: this is how I setup safe.fiery.me).
ClamAV support
This fork has an optional virus scanning support using ClamAV, utilizing clamscan library (Linux and OS X only).
It will scan new files right after they are uploaded, then alert the uploaders of the virus names in ClamAV's database if the files are dirty.
Unfortunately, this will slow down uploads processing as it has to wait for the scans before responding the uploaders. However, it's still highly recommended for public usage, or if you're like me who find the constant buzzing from Google Safe Search too annoying.
To enable this, make sure you have ClamAV installed, or additionally have ClamAV daemon running (using daemon is considerably faster). Afterwards configure uploads.scan
options, and more importantly its sub-option clamOptions
. Read more about it in the config.sample.js
file.
Additionally, you can also configure usergroups bypass, extensions whitelist, and max file size, to lessen the burden on your server.