Updated all dependencies.
Some latest version of dependencies such as bcrypt and sharp
requires Node 10+.
Updated fontello.css to uses latest version string from versions.js.
When updating version strings in commit
2670db269d, I forgot to rebuild this css.
Rebuilt all CSS assets, not sure why.
Probably due to browserslist being updated?
While I was as it, I also updated safe.fiery.me's node version to
10.19.0.
... and optionally videos using ffmpeg (still experimental).
Users can choose whether to strip tags of their uploads or not from
the home uploader's Config tab (safe.fiery.me will have it disabled
by default).
The behavior will also be applied to the downloadable ShareX config.
Server owners can choose to force either behavior.
Make sure to add the new config from config.sample.js.
---
Fixed all instances of "e.i." to "e.g.".
My English sucks okay.
Bumped v1 version string.
This doesn't use the server's built-in ability to accept multiple URLs
per API request.
It behaves the same as regular uploads, in that it executes one API call
per file, simultaneously.
I figured this is a better implementation to shift queues faster.
---
Fetch error from URL uploads due to exceeding size limit will no longer
be logged in server's console.
Clients will also see better formatted error message for URL uploads'
file size limit errors.
---
Bumped dependencies:
knex: 0.20.2 -> 0.20.3
systeminformation: 4.15.3 -> 4.16.0
Bumped v1 version string
Previously, margins in "Newer files on top" were bigger due to
difference in handling margins when in flex mode.
I noticed margins are still different in IE on my tests, but bleh.
Bumped v1 version string
As it turns out, Dropzone had a built-in timeout of 30 seconds.
There'll be no timeout now (thus respecting timeout settings of the
server and/or CDN).
While I was at it, I also refactored the bits for initializing Dropzone.
Also added a hacky method to handle Dropzone timeout,
in case someone wants to re-enable that.
"Hacky" due to lack of Dropzone's built-in timeout event handler.
Updated dev dependency:
eslint: 6.6.0 -> 6.7.1
bcrypt: 3.0.6 -> 3.0.7
knex: 0.20.1 -> 0.20.2
sharp: 0.23.2 -> 0.23.3
Dev dependency:
browserslist: 4.7.2 -> 4.7.3
As always, this was a full upgrade, so sub-dependencies were also
upgraded if applicable (more details in yarn.lock).
I noticed stylelint also got updated to v12, but I will be postponing
that till gulp-stylelint updates its peer dependency requirement.
Uploads thumbs view (dashboard) will no longer use smooth scrolling on
page change, etc.
This used to cause all thumbs to be loaded anyway when navigating with
its bottom pagination bar.
Bumped v1 version string.
---
Updated dependency:
systeminformation: 4.14.17 -> 4.15.3
Auto-close some Sweetalert success dialogs after 1.5s.
Fixed edit user not displaying user's new username properly.
Disabled eslint-plugin-compat on some lines that won't work in
Safari 5.1.
Optionally look into not supporting the browser altogether.
Bumped v1 version string.
Replaced all instances of DB .whereRaw with their much safer equivalent
methods.
All previous usages of .whereRaw were vulnerable to SQL injections,
cause we were passing the data directly.
Fortunately, they were only used in API routes that required staff
(moderators included) accounts.
---
Updated dependency:
helmet: 3.21.1 -> 3.21.2
Updated sample API rate limits.
This will pretty much be the same ones used live in safe.fiery.me.
This rate limits ALL API calls to 10 requests per second,
but apply stricter limits to login & register endpoints, which are
2 requests per 5 seconds.
Also apply stricter limit to album ZIP download endpoint to
4 requests in 30 seconds.
Also removed forcing 200 HTTP status code from the error responses,
cause front-end will now handle any HTTP status codes properly.
It was previously set to 200 cause frontend couldn't handler
errors properly.
On a side note, rate limiting all API calls is important due to the fact
that any token-based endpoints can be used for brute-forcing tokens.
Some server firewalls can also be used to ban possible brute force
attacks through actively monitoring the HTTP server's access logs,
so you may also want to consider that kind of solution for your site
instead.
