silverstripe-framework/docs/en/04_Changelogs/4.6.0.md

# 4.6.0

## Overview {#overview}

 * [MySQL tables are auto-converted from MyISAM to InnoDB](#myisam)
 * [Editing files directly in the insert-media modal](#in-modal-editing)
 * [MIME Type validation now a core module](#mime-validator)
 * [Solr no longer indexes draft/restricted content](#solr-updates)
 * [Simplify customisation of ModelAdmin](#modeladmin-customisation)
 * [Login forms module ships with installer](#loginforms)

## Security patches

This release contains security patches. Some of those patches might require some
updates to your project.

* [CVE-2020-9309 Script execution on protected files](https://www.silverstripe.org/download/security-releases/CVE-2020-9309)
* [CVE-2019-19326 Web Cache Poisoning](https://www.silverstripe.org/download/security-releases/CVE-2019-19326)
* [CVE-2020-6164 Information disclosure on /interactive URL path](https://www.silverstripe.org/download/security-releases/CVE-2020-6164)
* [CVE-2020-6165 Limited queries break CanViewPermissionChecker](https://www.silverstripe.org/download/security-releases/CVE-2020-6165)

### CVE-2020-9309 Script execution on protected files {#CVE-2020-9309}

Silverstripe can be susceptible to script execution from malicious upload
contents under allowed file extensions (for example HTML code in a TXT file).
When these files are stored as protected or draft files, the MIME detection can
cause browsers to execute the file contents.

#### Risk factors

If your project already includes the `silverstripe/mimevalidator` module, it's
already protected. CWP projects are already protected.

If your project includes the `silverstripe/userforms` module or allows anonymous
users to upload files, it's at a higher risk because malicious users can create
files without requiring a CMS access.

#### Actions you need to take

Upgrading to `silverstripe/recipe-core` 4.6.0 will automatically install the
`silverstripe/mimevalidator` module.

Read [MIME validator is now part of recipe-core](#MimeValidator) to understand
how this will impact your project.

### CVE-2019-19326 Web Cache Poisoning {#CVE-2019-19326}

Silverstripe sites using HTTP cache headers and HTTP caching proxies (e.g. CDNs) can be susceptible to web cache poisoning through the:
* `X-Original-Url` HTTP header
* `X-HTTP-Method-Override` HTTP header
* `_method` POST variable.

In order to remedy this vulnerability, Silverstripe Framework 4.6.0 removes native support for these features. While this is technically a semantic versioning breakage, these features are inherently insecure and date back to a time when browsers didn't natively support the full range of HTTP methods. Sites who still require these features will have highly unusual requirements that are best served by a tailored solution.

### Re-enabling the support for removed features

These features are best implemented by defining a `Middleware`.

The following example illustrates how to implement an `HTTPMiddleware` that restores support for the `X-Original-Url` header and the `_method` POST parameter for requests originating from a trusted proxy.

```php
<?php

use SilverStripe\Control\Middleware\HTTPMiddleware;
use SilverStripe\Control\HTTPRequest;

/**
 * This is meant to illustrate how to implement an HTTPMiddleware. If you blindly
 * copy-paste this in in your code base, you'll simply replicate the vulnerability.
 */
class InsecureHeaderMiddleware implements HTTPMiddleware
{
    public function process(HTTPRequest $request, callable $delegate)
    {
        // Normally, you would validate that the request is coming from a trusted source at this point.
        // View SilverStripe\Control\Middleware\TrustedProxyMiddleware for an example.
        $trustedProxy = true;

        if ($trustedProxy) {
            $originalUrl = $request->getHeader('X-Original-Url');
            if ($originalUrl) {
                $_SERVER['REQUEST_URI'] = $originalUrl;
                $request->setUrl($originalUrl);
            }

            $methodOverride = $request->postVar('_method');
            $validMethods = ['GET', 'POST', 'PUT', 'DELETE', 'HEAD'];
            if ($methodOverride && in_array(strtoupper($methodOverride), $validMethods)) {
                $request->setHttpMethod($methodOverride);
            }
        }

        return $delegate($request);
    }
}
```

To learn more about re-implementing support for the disabled features:
* read [how to configure trusted proxies](/developer_guides/security/secure_coding/#request-hostname-forgery) on the Silverstripe documentation.
* read the [documentation about HTTP Middlewares](/developer_guides/controllers/middlewares/).

### CVE-2020-6164 Information disclosure on /interactive URL path

A specific URL path configured by default through the silverstripe/framework module can be used to disclose the fact that a domain is hosting a Silverstripe application. There is no disclosure of the specific version. The functionality on this URL path is limited to execution in a CLI context, and is not known to present a vulnerability through web-based access. As a side-effect, this preconfigured path also blocks the creation of other resources on this path (e.g. a page).

### CVE-2020-6165 Limited queries break CanViewPermissionChecker

The automatic permission checking mechanism in the silverstripe/graphql module does not provide complete protection against lists that are limited (e.g. through pagination), resulting in records that should fail the permission check being added to the final result set.

If your project implements custom GraphQL queries using the `CanViewPermissionChecker`, you should validate that they still work as expected after the upgrade.

Read [Controlling who can view results in a GraphQL result set](/Developer_Guides/GraphQL/Verifying_CanView_Permission)
for more information on updating your GraphQL queries.

## MySQL tables are auto-converted from MyISAM to InnoDB {#myisam}

Beginning with [4.4.0](https://docs.silverstripe.org/en/4/changelogs/4.4.0/),
our minimum requirement for MySQL is 5.6 (since MySQL 5.5 end of life reached
in December 2018). Starting with MySQL 5.6, [InnoDB](https://dev.mysql.com/doc/refman/5.6/en/innodb-introduction.html)
is the new default storage engine, replacing the older [MyISAM](https://dev.mysql.com/doc/refman/5.6/en/myisam-storage-engine.html)
engine.

Silverstripe CMS already creates InnoDB tables by default,
mainly in order to benefit from their better support for database transactions.
Before MySQL 5.6, InnoDB didn't have a `FULLTEXT` search index,
requiring us to enforce the MyISAM engine when devs opted into this index type
in their particular setup. There are a few ways in which this opt-in can happen:

 * Adding the [FulltextSearchable](https://github.com/silverstripe/silverstripe-framework/blob/4/src/ORM/Search/FulltextSearchable.php)
   extension to a DataObject, as described in our
   [search docs](https://docs.silverstripe.org/en/4/developer_guides/search/fulltextsearch/)
 * Defining `'type' => 'fulltext'` in `DataObject::$db` column definitions
 * Implementing [DBIndexable](https://github.com/silverstripe/silverstripe-framework/blob/4/src/ORM/FieldType/DBIndexable.php)
   on a custom `DBField` subclass.
 * Setting `'ENGINE=MyISAM'` in `DataObject::$create_table_options`

This search index is not required to enable simple text search
in the "Pages" section of the CMS, or any ModelAdmin implementations.
We generally recommend to choose a more powerful
[search addon](https://addons.silverstripe.org/add-ons?search=fulltext&type=&sort=downloads)
(e.g. based on Solr or ElasticSearch) for website frontend search use cases.

As of 4.6.0, a `dev/build` will automatically switch MyISAM tables to InnoDB,
which automatically recreates any indexes required. If you have large indexes,
this can extend the duration if this task. As usual, back up your database
before upgrading, and test upgrades on non-production systems first.
Our tests indicate that indexes with thousands of records and screen pages
worth of content (15MB index size) are converted in a few seconds.

In order to opt out of this change, you can set the engine explicitly
for your DataObject implementations:

```php
use SilverStripe\ORM\Connect\MySQLSchemaManager;
use SilverStripe\ORM\DataObject;

class MyDataObject extends DataObject
{
    private static $create_table_options = [
            MySQLSchemaManager::ID => 'ENGINE=MyISAM'
    ];
}
```

## Editing files directly in the insert-media modal{#in-modal-editing}

Editors can now directly edit file details when selecting a file in an
UploadField or when inserting media in a HTMLEditorField. The "image placement"
and "file link" forms that show when inserting an image or a link in an
HTMLEditorField have been simplified.

This does mean that the order and structure of fields have changed somewhat. If
you have customised the forms in the asset administration area or in the
"Insert Media Modal", you should do some regression testing when upgrading to
make sure your customisations still work as expected.

If your project uses the popular [jonom/focuspoint](https://github.com/jonom/silverstripe-focuspoint)
community module, you should upgrade it as well.

## MIME Type validation now a core module {#mime-validator}

The Silverstripe CMS installer now includes the `silverstripe/mimevalidator`.
This change was implemented to address `CVE-2020-9309` vulnerability and the
inherent limits of controlling allowed file types by looking only at file
extensions.

For most Silverstripe CMS projects, this will be a transparent upgrade. However,
they are some situations where you might need to make some adjustments.

### Who will get MIME validator installed automatically?

If your Silverstripe CMS project references `silverstripe/recipe-core` or
`silverstripe/recipe-cms` in its `composer.json` file,
`silverstripe/mimevalidator` will be automatically installed once you upgrade to
Silverstripe CMS 4.6.0. Those recipes might also be indirectly installed via
other recipes (e.g.: `cwp/cwp-recipe-core`). You can run this command from your
project root to know for sure:

```bash
composer show silverstripe/recipe-core
```

If you get an error, you will not be automatically get
`silverstripe/mimevalidator` following your upgrade.

After upgrading your project, composer should automatically create the following
file in your project: `app/_config/mimevalidator.yml`. This file contains the
default configuration for the new module. You'll need to commit
`mimevalidator.yml` and your updated `composer.json` file to your source control
system.

### If you're not using recipe-core/recipe-cms?

If your project doesn't reference `silverstripe/recipe-core` or
`silverstripe/recipe-cms`, you will need to manually add
`silverstripe/mimevalidator` to your project dependencies. Run this command to
install `silverstripe/mimevalidator`:

```bash
composer require silverstripe/mimevalidator
```

Then, add this code snippet to your YML configuration to enable MIME type
validation:

```yml
SilverStripe\Core\Injector\Injector:
  SilverStripe\Assets\Upload_Validator:
    class: SilverStripe\MimeValidator\MimeUploadValidator
```

### Customising allowed file types

If you've customised your project allowed file types, you might need to tweak
the boilerplate MIME validator configuration and confirm the new module doesn't
interfere with your existing logic.

Read [Allowed file types](/Developer_Guides/Files/Allowed_file_types) in the
Silverstripe CMS documentation to learn how to Control the type of files that
can be stored in your project.

### What if the MIME validator module is already installed?

If your project already requires `silverstripe/mimevalidator`, you probably
don't need to do anything.

If you didn't have a pre-existing `app/_config/mimevalidator.yml` file and your
MIME validator configuration is contained somewhere else in your project, feel
free to discard `mimevalidator.yml`.

If you explicitly required `silverstripe/mimevalidator` in your `composer.json`
file, you can remove the explicit reference and rely on the module being
installed via the recipes.

If your version constrain for `silverstripe/mimevalidator` in your
`composer.json` is too strict, you might get an error while upgrading to the
latest version of `recipe-core`. If this occurs, either loosen the constraint
for `silverstripe/mimevalidator` or remove it altogether.

### What if I don't want the MIME validator module?

This is not advise, but you can upgrade to Silverstripe CMS 4.6.0 without
installing the `silverstripe/mimevalidator` module.

To achieve this, you will need to "inline" recipes in your `composer.json`. This
means you will have an explicit dependency for each individual Silverstripe CMS
module. You can inline recipes by running this command.

```bash
composer require-recipe silverstripe/recipe-cms
```

Then you just need to remove the reference to `silverstripe/mimevalidator`.

Beware that this will make future upgrade more difficult because you will have
to manually edit each module constraint.

## File status icons in the file manager

![File status icons](https://raw.githubusercontent.com/silverstripe/silverstripe-framework/blob/4/docs/en/04_Changelogs/_images/file-status-icons.png "A screenshot of file status icons being displayed in the file manager")

Files and folders with permissions of either "Logged in users" or "Only these
groups (choose from list)" now show a "Restricted access" icon in the file
manager.  These permissions can either be directly on the DataObject or they can
be inherited from the parent folder.

Websites with the optional [UserForms](https://github.com/silverstripe/silverstripe-userforms)
module installed will show a "Form submission" icon on files uploaded through a
UserForm.  UserForm uploaded files without a "Restricted access" icon show a
"Form submission, unrestricted access" icon instead.

## Solr no longer indexes draft/restricted content {#solr-updates}

At the time of this release a new version of the popular [silverstripe/fulltextsearch module](https://github.com/silverstripe/silverstripe-fulltextsearch) is also available, introducing more secure defaults. Most notably, draft and restricted content will no longer be indexed by default, due to a `canView()` check being performed against an anonymous user prior to (re)indexing. Restricted content means that it has a permission level of either 'Logged-in users' or 'Only these groups'.

If your project uses this module, after upgrading your website, ensure that you run the `Solr_Reindex` task on your production environment to remove previously indexed content that should no longer be there.

If your website requires draft or restricted content to be indexed, you can opt-out of the new secure defaults on a per-model basis.

This is a great opportunity to make sure that any custom indexes/search controllers in your project are correctly filtering results based on permissions and search visibility, which you can now achieve via a unified method (see `SilverStripe\FullTextSearch\Search\Services\SearchableService::isSearchable()`.)

The [silverstripe/fulltextsearch module readme provides additional information](https://github.com/silverstripe/silverstripe-fulltextsearch).

## Simplify customisation of ModelAdmin {#modeladmin-customisation}

`ModelAdmin::getEditForm()` has been split into smaller more discrete protected methods:
* `getGridField()`
* `getGridFieldConfig()`.

Two matching extension hooks have been added as well:
* `updateGridField()`
* `updateGridFieldConfig()`.

This will make it easier for developers to customise GridFields in their ModelAdmins.

Learn how to [alter the ModelAdmin GridField or Form](/developer_guides/customising_the_admin_interface/modeladmin/#altering-the-modeladmin-gridfield-or-form)

## Login forms module ships with installer {#loginforms}

The `silverstripe/login-forms` module is now part of the default installer. This alters the login form to provide
consistent styling and behaviour that's independent from the specifics in your project. Only new projects will
get the new login form. Older projects can manually require the `silverstripe/login-forms` module to get the new
login form.

View the [Silverstripe Login Forms readme](https://github.com/silverstripe/silverstripe-login-forms) on Github for more details.
<!--- Changes below this line will be automatically regenerated -->

<!--- Changes above this line will be automatically regenerated -->