Replaces the old suggestion of setting JS head 'window.uploadLimit'
variable. This new env option will be used by back-end validation and
front-end libs/logic too.
Limits already likely exist within prod environments at a PHP and
webserver level but this allows an app-level limit and centralises the
option on the BookStack side into the .env
Closes#3033
- Moved out extension check to ImageService as that seems more relevant.
- Updated models to use static-style references instead of facade to align with common modern usage within the app.
- Updated custom image_extension validation rule to use shared logic in image service.
- Files within the storage/ path could be accessed via path traversal
references in content, accessed upon HTML export.
- This addresses this via two layers:
- Scoped local flysystem filesystems down to the specific image &
file folders since flysystem has built-in checking against the
escaping of the root folder.
- Added path normalization before enforcement of uploads/{images,file}
prefix to prevent traversal at a path level.
Thanks to @Haxatron via huntr.dev for discovery and reporting.
Ref: https://huntr.dev/bounties/ac268a17-72b5-446f-a09a-9945ef58607a/
A query string will cause attachments to be provided inline
with an appropriate mime type.
Remaining actions:
- Tests
- Front-end functionality
- Config option?
- Added test cases to cover.
- Altered parsing logic to be a little less reliant on regex.
- Added new iamge repo method for creating from data.
- Added extension validation and additional type support.
- Done some cleanup of common operations within PageContent.
- Added message to API docs/method to mention image usage.
For #2700 and #2631.
- Reduced options to single new configuration paramter instead of two.
- Moved more logic into UserAvatars class.
- Updated LDAP avatar import to also run on login when no image is
currently set.
- Added thumbnail fetching to search requests.
- Added testing to cover.
Related to PR #2320, and issue #1161
To ensure thhat the visibility is still set on local storage options
since the previous recent changes could cause problems where in
scenarios where the server user could not read images uploaded by the
php process user.
Closes#2758
The content of pages made non-viewable to a user via permissions, within a visible parent, could be seen via the plaintext export option. Before v0.30.6 this would have applied only to scenarios where all pages within the chapter were made non-visible. In v0.30.6 this would make all pages within the chapter visible.
As per #2414
This filters out potentially malicious javascript: or data: uri's coming
through to be attached to attachments.
Added tests to cover.
Thanks to Yassine ABOUKIR (@yassineaboukir on twitter) for reporting this
vulnerability.
