tonyair
/
silverstripe-framework
mirror of https://github.com/silverstripe/silverstripe-framework
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update changelog

This commit is contained in:
Aaron Carlino 2019-09-25 11:23:57 +12:00
parent af6644f762
commit b0a17f5df1
2 changed files with 38 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
docs/en/04_Changelogs/4.3.5.md
View File

@ -1,42 +0,0 @@
# 4.3.5
Embedding files with shortcodes (`FileShortcodeProvider`) no longer provides a session grant
by default. This is because it has the potential to escalate file access
to users who otherwise should not have viewing permissions for the file.
There is a minor performance trade-off for disabling these grants. If you have a page with a lot of
images that are in a draft state or have custom viewing permissions, it adds an extra database
query for each embedded image. With session grants enabled, the first permission check persists
the grant into the session, meaning there is no need to query the database on every single file.
Unless you have a lot of shortcode images embedded with protected or draft status on a single page,
this setting is best left to its default value of `false`.
To revert to the old behaviour:
```
SilverStripe\Assets\Shortcodes\FileShortcodeProvider:
allow_session_grant: true
```
## If you were using the versionedfiles on your 3.x site
This release includes a security fix for users who migrated from a 3.x site that used
the [versionedfiles](https://github.com/symbiote/silverstripe-versionedfiles) module.
The file migration would have left the `_versions` folders in your public filesystem
as artefacts, leaving all the unpublished versions of your old files publicly accessible
under a guessable URL.
To work around this, you can use the `VersionedFilesMigrationTask`:
`$ vendor/bin/sake dev/tasks/migrate-versionedfiles strategy=[delete|protect]`
If you choose the `delete` strategy (default), the task will delete all `_versions`
files for you. Be sure to take a snapshot of your `public/assets` folder before
doing so. If you choose the `protect` strategy, the task will drop an `.htaccess` file
in your old `_versions` directories. **This method only works if you are using Apache
to serve your static files**. If you are using another server such as Nginx, these files
will remain publicly exposed. It is recommended you use the `delete` strategy if you are
not using Apache.
<!--- Changes below this line will be automatically regenerated -->

38
docs/en/04_Changelogs/4.3.6.md
View File

@ -1,5 +1,43 @@
# 4.3.6
Embedding files with shortcodes (`FileShortcodeProvider`) no longer provides a session grant
by default. This is because it has the potential to escalate file access
to users who otherwise should not have viewing permissions for the file.
There is a minor performance trade-off for disabling these grants. If you have a page with a lot of
images that are in a draft state or have custom viewing permissions, it adds an extra database
query for each embedded image. With session grants enabled, the first permission check persists
the grant into the session, meaning there is no need to query the database on every single file.
Unless you have a lot of shortcode images embedded with protected or draft status on a single page,
this setting is best left to its default value of `false`.
To revert to the old behaviour:
```
SilverStripe\Assets\Shortcodes\FileShortcodeProvider:
allow_session_grant: true
```
## If you were using the versionedfiles on your 3.x site
This release includes a security fix for users who migrated from a 3.x site that used
the [versionedfiles](https://github.com/symbiote/silverstripe-versionedfiles) module.
The file migration would have left the `_versions` folders in your public filesystem
as artefacts, leaving all the unpublished versions of your old files publicly accessible
under a guessable URL.
To work around this, you can use the `VersionedFilesMigrationTask`:
`$ vendor/bin/sake dev/tasks/migrate-versionedfiles strategy=[delete|protect]`
If you choose the `delete` strategy (default), the task will delete all `_versions`
files for you. Be sure to take a snapshot of your `public/assets` folder before
doing so. If you choose the `protect` strategy, the task will drop an `.htaccess` file
in your old `_versions` directories. **This method only works if you are using Apache
to serve your static files**. If you are using another server such as Nginx, these files
will remain publicly exposed. It is recommended you use the `delete` strategy if you are
not using Apache.
## Change Log