Merge branch '4.6' into 4

.upgrade.yml

@@ -205,8 +205,6 @@ mappings:
   FunctionalTest: SilverStripe\Dev\FunctionalTest
   InstallerTest: SilverStripe\Dev\InstallerTest
   MigrationTask: SilverStripe\Dev\MigrationTask
-  SapphireInfo: SilverStripe\Dev\SapphireInfo
-  SapphireREPL: SilverStripe\Dev\SapphireREPL
   SapphireTest: SilverStripe\Dev\SapphireTest
   TaskRunner: SilverStripe\Dev\TaskRunner
   TestMailer: SilverStripe\Dev\TestMailer
@@ -1016,6 +1014,14 @@ warnings:
       message: 'Use SilverStripe\CMS\BatchActions\CMSBatchAction_Archive instead'
     'EncryptAllPasswordsTask':
       message: 'Removed'
+    'SapphireInfo':
+      message: 'Removed'
+    'SilverStripe\Dev\SapphireREPL':
+      message: 'Removed'
+    'SilverStripe\Dev\SapphireInfo':
+      message: 'Deprecated'
+    'SilverStripe\Dev\InstallerTest':
+      message: 'Deprecated'
   methods:
     'SilverStripe\Security\Authenticator::register()':
       message: 'Custom authenticators work differently now'

_config/routes.yml

@@ -14,10 +14,6 @@ SilverStripe\Control\Director:
     'Security//$Action/$ID/$OtherID': SilverStripe\Security\Security
     'CMSSecurity//$Action/$ID/$OtherID': SilverStripe\Security\CMSSecurity
     'dev': SilverStripe\Dev\DevelopmentAdmin
-    'interactive': SilverStripe\Dev\SapphireREPL
-    'InstallerTest//$Action/$ID/$OtherID': SilverStripe\Dev\InstallerTest
-    'SapphireInfo//$Action/$ID/$OtherID': SilverStripe\Dev\SapphireInfo
-    'SapphireREPL//$Action/$ID/$OtherID': SilverStripe\Dev\SapphireREPL
 ---
 Name: security-limited
 After:

docs/en/02_Developer_Guides/19_GraphQL/01_Verifying_CanView_Permission.md

@@ -0,0 +1,159 @@
+---
+title: Controlling CanView access to DataObjects returned by GraphQL 
+summary: Your GraphQL service should honour the CanView permission when fetching DataObjects. Learn how to customise this access control check.   
+icon: cookie-bite
+---
+
+# Controlling who can view results in a GraphQL result set
+
+The [Silverstripe ORM provides methods to control permissions on DataObject](Developer_Guides/Model/Permissions). In 
+most cases, you'll want to extend this permission model to any GraphQL service you implement that returns a DataObject.
+
+## The QueryPermissionChecker interface
+
+The GraphQL module includes a `QueryPermissionChecker` interface. This interface can be used to specify how GraphQL 
+services should validate that users have access to the DataObjects they are requesting.
+
+The default implementation of `QueryPermissionChecker` is `CanViewPermissionChecker`. `CanViewPermissionChecker` directly calls the `CanView` method of each DataObject in your result set and filters out the entries not visible to the current user.
+
+Out of the box, the `CanView` permission of your DataObjects are honoured when Scaffolding GraphQL queries.
+
+## Customising how the results are filtered
+
+`CanViewPermissionChecker` has some limitations. It's rather simplistic and will load each entry in your results set to perform a CanView call on it. It will also convert the results set to an `ArrayList` which can be inconvenient if you need to alter the underlying query after the _CanView_ check.
+
+Depending on your exact use case, you may want to implement your own `QueryPermissionChecker` instead of relying 
+on `CanViewPermissionChecker`.
+
+Some of the reasons you might consider this are:
+* the access permissions on your GraphQL service differ from the ones implemented directly on your DataObject
+* you want to speed up your request by filtering out results the user doesn't have access to directly in the query
+* you would rather have a `DataList` be returned.
+
+### Implementing your own QueryPermissionChecker class
+
+The `QueryPermissionChecker` requires your class to implement two methods:
+* `applyToList` which filters a `Filterable` list based on whether a provided `Member` can view the results
+* `checkItem` which checks if a provided object can be viewed by a specific `Member`.
+
+#### Filtering results based on the user's permissions 
+
+In some context, whether a user can view an object is entirely determined on their permissions. When that's the
+case, you don't even need to get results to know if the user will be able to see them or not.
+
+```php
+<?php
+use SilverStripe\GraphQL\Permission\QueryPermissionChecker;
+use SilverStripe\ORM\ArrayList;
+use SilverStripe\ORM\Filterable;
+use SilverStripe\Security\Member;
+use SilverStripe\Security\Permission;
+
+/**
+* This implementation assumes that only users with the ADMIN permission can view results.
+*/
+class AdminPermissionChecker implements QueryPermissionChecker
+{
+
+    public function applyToList(Filterable $list, Member $member = null)
+    {
+        return Permission::check('ADMIN', 'any', $member) ?
+        $list :
+        ArrayList::create([]);
+    }
+
+    public function checkItem($item, Member $member = null)
+    {
+        return Permission::check('ADMIN', 'any', $member);
+    }
+}
+```
+
+#### Filtering results based on the user's permissions 
+
+Some times, whether a user can view an object is determined by some information on the record. If that's the case,
+you can filter out results the user can not see by altering the query. This has some performance advantage, because 
+the results are filtered directly by the query.
+
+```php
+<?php
+use SilverStripe\GraphQL\Permission\QueryPermissionChecker;
+use SilverStripe\ORM\Filterable;
+use SilverStripe\Security\Member;
+
+/**
+ * This implementation assumes that the results are assigned an owner and that only the owner can view a record.
+ */
+class OwnerPermissionChecker implements QueryPermissionChecker
+{
+
+    public function applyToList(Filterable $list, Member $member = null)
+    {
+        return $list->filter('OwnerID', $member ? $member->ID : -1);
+    }
+
+    public function checkItem($item, Member $member = null)
+    {
+        return $member && $item->OwnerID === $member->ID;
+    }
+}
+```
+
+### Using a custom QueryPermissionChecker implementation
+
+There's three classes that expect a `QueryPermissionChecker`:
+* `SilverStripe\GraphQL\Scaffolding\Scaffolders\ItemQueryScaffolder`
+* `SilverStripe\GraphQL\Scaffolding\Scaffolders\ListQueryScaffolder`
+* `SilverStripe\GraphQL\Pagination\Connection`
+
+Those classes all implement the `SilverStripe\GraphQL\Permission\PermissionCheckerAware` and receive the default
+`QueryPermissionChecker` from the Injector. They also have a `setPermissionChecker` method that can be use to provide a custom `QueryPermissionChecker`.
+
+#### Scaffolding types with a custom QueryPermissionChecker implementation 
+
+There's not any elegant way of defining a custom `QueryPermissionChecker` when scaffolding types at this time. If 
+you need the ability to use a custom `QueryPermissionChecker`, you'll have to build your query manually.
+
+#### Overriding the QueryPermissionChecker for a class extending ListQueryScaffolder
+
+If you've created a GraphQL query by creating a subclass of `ListQueryScaffolder`, you can use the injector to
+override `QueryPermissionChecker`.
+
+```yaml
+---
+Name: custom-graphqlconfig
+After: graphqlconfig
+---
+SilverStripe\Core\Injector\Injector:
+  SilverStripe\GraphQL\Permission\QueryPermissionChecker.my-custom:
+    class: App\Project\CustomQueryPermissionChecker
+  App\Project\CustomListQueryScaffolder:
+    properties:
+      permissionChecker: '%$SilverStripe\GraphQL\Permission\QueryPermissionChecker.my-custom'
+```
+
+#### Manually specifying a QueryPermissionChecker on a Connection
+
+If you're manually instantiating an instance of `SilverStripe\GraphQL\Pagination\Connection` to resolve your results,
+you can pass an instance of your own custom `QueryPermissionChecker`.
+
+```php
+$childrenConnection = Connection::create('Children')
+    ->setConnectionType($this->manager->getType('Children'))
+    ->setSortableFields([
+        'id' => 'ID',
+        'title' => 'Title',
+        'created' => 'Created',
+        'lastEdited' => 'LastEdited',
+    ])
+    ->setPermissionChecker(new CustomQueryPermissionChecker());
+```
+
+## API Documentation
+
+* [CanViewPermissionChecker](api:SilverStripe\GraphQL\Permission\CanViewPermissionChecker)
+* [Connection](api:SilverStripe\GraphQL\Pagination\Connection)
+* [ItemQueryScaffolder](api:SilverStripe\GraphQL\Scaffolding\Scaffolders\ItemQueryScaffolder)
+* [ListQueryScaffolder](api:SilverStripe\GraphQL\Scaffolding\Scaffolders\ListQueryScaffolder)
+* [PermissionCheckerAware](api:SilverStripe\GraphQL\Permission\PermissionCheckerAware)
+* [QueryPermissionChecker](api:SilverStripe\GraphQL\Permission\QueryPermissionChecker)

docs/en/02_Developer_Guides/19_GraphQL/index.md

@@ -0,0 +1,20 @@
+---
+title: GraphQL
+summary: Learn how to create and customise GraphQL services on your Silverstripe CMS project.
+introduction: Learn how to create and customise GraphQL services on your Silverstripe CMS project.
+icon: cookie
+---
+
+[CHILDREN]
+
+## Additional documentation
+
+A substantial part of the GraphQL documentation for Silverstripe CMS still 
+reside on the GraphQL module's _Readme_ file. We are in the process of folding
+this information back into the main Silverstripe CMS documentation.
+
+* [silverstripe/graphql](https://github.com/silverstripe/silverstripe-graphql/)
+
+## API Documentation
+
+* [GraphQL](api:SilverStripe\GraphQL)

docs/en/04_Changelogs/4.4.7.md

@@ -0,0 +1,131 @@
+# 4.4.7
+
+## 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-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
+
+If your project already includes the `silverstripe/mimevalidator` module, you do not need to do anything. To check if the `silverstripe/mimevalidator` module is installed in your project, run this command from your project root.
+
+```sh
+composer show silverstripe/mimevalidator
+```
+
+If you get an error, the module is not installed.
+
+**Upgrading to `silverstripe/recipe-cms` 4.4.7 will NOT automatically install `silverstripe/mimevalidator`**. You need to manually install the module `silverstripe/mimevalidator`. To add `silverstripe/mimevalidator` to your project, run this command.
+
+```sh
+composer require silverstripe/mimevalidator
+```
+
+After installing the `mimevalidator` module, you need to enable it by adding this code snippet to your YML configuration.
+
+```yml
+SilverStripe\Core\Injector\Injector:
+  SilverStripe\Assets\Upload_Validator:
+    class: SilverStripe\MimeValidator\MimeUploadValidator
+```
+
+If your project overrides the defaults allowed file types, it's important that you take the time to review your configuration and adjust it as need be to work with `silverstripe/mimevalidator`.
+
+Read the [Allowed file types](/Developer_Guides/Files/Allowed_file_types) documentation for more details on controling the type of files that can be stored in your Silverstrip CMS Project.
+
+#### Special consideration when upgrading Userforms
+
+The `silverstripe/userforms` module now also includes `silverstripe/mimevalidator` in its dependencies. Upgrading to the following versions of userforms will automatically install `silverstripe/mimevalidator`:
+
+* 5.4.3 or later
+* 5.5.3 or later
+* 5.6.0 or later (requires CMS 4.6.0)
+
+Userforms that include a file upload field will automatically use the`MimeUploadValidator`. Beware that this will NOT change the default upload validator for other file upload fields in the CMS. You'll need to update your YML configuration for the `MimeUploadValidator` to be used everywhere.
+
+### 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.4.7 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).
+
+<!--- Changes below this line will be automatically regenerated -->
+
+## Change Log
+
+### Security
+
+ * 2020-05-13 [91d30db88](https://github.com/silverstripe/silverstripe-framework/commit/91d30db88f68b9b87980ef9a59e208a81980b72c) Remove/deprecate unused controllers that can potentially give away some information about the underlying project. (Maxime Rainville) - See [cve-2020-6164](https://www.silverstripe.org/download/security-releases/cve-2020-6164)
+ * 2020-05-11 [107706c12](https://github.com/silverstripe/silverstripe-framework/commit/107706c12cd9cf4d1b8b96b6a6e223633209d851) Stop honouring X-HTTP-Method-Override header, X-Original-Url header and _method POST variable. Add SS_HTTPRequest::setHttpMethod() (Maxime Rainville) - See [cve-2019-19326](https://www.silverstripe.org/download/security-releases/cve-2019-19326)
+
+### Bugfixes
+
+ * 2020-06-01 [3df2222](https://github.com/silverstripe/silverstripe-asset-admin/commit/3df222203ee563fac840e5e0727c75ddfe244886) Prevent react-selectable from interfering with pagination (Maxime Rainville)
+ * 2020-05-05 [2cc037b](https://github.com/silverstripe/silverstripe-versioned/commit/2cc037b2d305ed98056a9232587351949e59561f) Fix merge conflict in Travis configuration (Robbie Averill)
+ * 2020-02-24 [bba0f2f72](https://github.com/silverstripe/silverstripe-framework/commit/bba0f2f72fa2e631dbf60357a908d5d57d4467ee) Fixed issue where TimeField_Readonly would only show "(not set)" instead of the value (UndefinedOffset)
+ * 2020-02-18 [e0de15f](https://github.com/silverstripe/silverstripe-errorpage/commit/e0de15f85a09ac848cb110f49cef58624d1e892f) Fix broken test when FulltextSearchable is enabled (Maxime Rainville)
+ * 2019-09-02 [6d8a4bc](https://github.com/silverstripe/silverstripe-assets/commit/6d8a4bc4f4178c0b56ede1b01f87b162066d550a) Make AbsoluteLink work with manipulated images (fixes #322) (Loz Calver)
+<!--- Changes above this line will be automatically regenerated -->