Merge branch '3.4' into 4.0

* 3.4:
  Update the documentation for Symfony Flex
  Improved the multiple user providers article
  Removed a no longer relevant text
  Update NotBlank constraint description
  add missing argument binding section
  Added a minor note about Composer's plaform config
  Update 3.3-di-changes.rst
  added initial_place entry
  added initial_place entry
  [FrameworkBundle] add documentation request context in Asset for use in console commands
  Update choice_attr.rst.inc

Author: javiereguiluz

console/request_context.rst

@@ -21,8 +21,8 @@ Configuring the Request Context Globally
 
 To configure the Request Context - which is used by the URL Generator - you can
 redefine the parameters it uses as default values to change the default host
-(``localhost``) and scheme (``http``). You can also configure the base path if
-Symfony is not running in the root directory.
+(``localhost``) and scheme (``http``). You can also configure the base path (both for
+the URL generator and the assets) if Symfony is not running in the root directory.
 
 Note that this does not impact URLs generated via normal web requests, since those
 will override the defaults.
@@ -36,6 +36,8 @@ will override the defaults.
             router.request_context.host: example.org
             router.request_context.scheme: https
             router.request_context.base_url: my/path
+            asset.request_context.base_path: %router.request_context.base_url%
+            asset.request_context.secure: true
 
     .. code-block:: xml
 
@@ -48,6 +50,8 @@ will override the defaults.
                 <parameter key="router.request_context.host">example.org</parameter>
                 <parameter key="router.request_context.scheme">https</parameter>
                 <parameter key="router.request_context.base_url">my/path</parameter>
+                <parameter key="asset.request_context.base_path">%router.request_context.base_url%</parameter>
+                <parameter key="asset.request_context.secure">true</parameter>
             </parameters>
 
         </container>
@@ -58,6 +62,11 @@ will override the defaults.
         $container->setParameter('router.request_context.host', 'example.org');
         $container->setParameter('router.request_context.scheme', 'https');
         $container->setParameter('router.request_context.base_url', 'my/path');
+        $container->setParameter('asset.request_context.base_path', $container->getParameter('router.request_context.base_url'));
+        $container->setParameter('asset.request_context.secure', true);
+
+.. versionadded:: 3.4
+    The ``asset.request_context.*`` parameters were introduced in Symfony 3.4.
 
 Configuring the Request Context per Command
 -------------------------------------------

contributing/code/security.rst

@@ -37,7 +37,6 @@ confirmed, the core team works on a solution following these steps:
 #. Package new versions for all affected versions;
 #. Publish the post on the official Symfony `blog`_ (it must also be added to
    the "`Security Advisories`_" category);
-#. Update the security advisory list (see below).
 #. Update the public `security advisories database`_ maintained by the
    FriendsOfPHP organization and which is used by the ``security:check`` command.
 
@@ -100,47 +99,13 @@ Security Advisories
     You can check your Symfony application for known security vulnerabilities
     using the ``security:check`` command (see :doc:`/security/security_checker`).
 
-This section indexes security vulnerabilities that were fixed in Symfony
-releases, starting from Symfony 1.0.0:
-
-* Jul 17, 2017, `CVE-2017-11365: Empty passwords validation issue <https://symfony.com/blog/cve-2017-11365-empty-passwords-validation-issue>`_ (2.7.30, 2.7.31, 2.8.23, 2.8.24, 3.2.10, 3.2.11, 3.3.3, and 3.3.4)
-* May 9, 2016: `CVE-2016-2403: Unauthorized access on a misconfigured Ldap server when using an empty password <https://symfony.com/blog/cve-2016-2403-unauthorized-access-on-a-misconfigured-ldap-server-when-using-an-empty-password>`_ (2.8.0-2.8.5, 3.0.0-3.0.5)
-* May 9, 2016: `CVE-2016-4423: Large username storage in session <https://symfony.com/blog/cve-2016-4423-large-username-storage-in-session>`_ (2.3.0-2.3.40, 2.7.0-2.7.12, 2.8.0-2.8.5, 3.0.0-3.0.5)
-* January 18, 2016: `CVE-2016-1902: SecureRandom's fallback not secure when OpenSSL fails <https://symfony.com/blog/cve-2016-1902-securerandom-s-fallback-not-secure-when-openssl-fails>`_ (2.3.0-2.3.36, 2.6.0-2.6.12, 2.7.0-2.7.8)
-* November 23, 2015: `CVE-2015-8125: Potential Remote Timing Attack Vulnerability in Security Remember-Me Service <https://symfony.com/blog/cve-2015-8125-potential-remote-timing-attack-vulnerability-in-security-remember-me-service>`_ (2.3.35, 2.6.12 and 2.7.7)
-* November 23, 2015: `CVE-2015-8124: Session Fixation in the "Remember Me" Login Feature <https://symfony.com/blog/cve-2015-8124-session-fixation-in-the-remember-me-login-feature>`_ (2.3.35, 2.6.12 and 2.7.7)
-* May 26, 2015: `CVE-2015-4050: ESI unauthorized access <https://symfony.com/blog/cve-2015-4050-esi-unauthorized-access>`_ (Symfony 2.3.29, 2.5.12 and 2.6.8)
-* April 1, 2015: `CVE-2015-2309: Unsafe methods in the Request class <https://symfony.com/blog/cve-2015-2309-unsafe-methods-in-the-request-class>`_ (Symfony 2.3.27, 2.5.11 and 2.6.6)
-* April 1, 2015: `CVE-2015-2308: Esi Code Injection <https://symfony.com/blog/cve-2015-2308-esi-code-injection>`_ (Symfony 2.3.27, 2.5.11 and 2.6.6)
-* September 3, 2014: `CVE-2014-6072: CSRF vulnerability in the Web Profiler <https://symfony.com/blog/cve-2014-6072-csrf-vulnerability-in-the-web-profiler>`_ (Symfony 2.3.19, 2.4.9 and 2.5.4)
-* September 3, 2014: `CVE-2014-6061: Security issue when parsing the Authorization header <https://symfony.com/blog/cve-2014-6061-security-issue-when-parsing-the-authorization-header>`_ (Symfony 2.3.19, 2.4.9 and 2.5.4)
-* September 3, 2014: `CVE-2014-5245: Direct access of ESI URLs behind a trusted proxy <https://symfony.com/blog/cve-2014-5245-direct-access-of-esi-urls-behind-a-trusted-proxy>`_ (Symfony 2.3.19, 2.4.9 and 2.5.4)
-* September 3, 2014: `CVE-2014-5244: Denial of service with a malicious HTTP Host header <https://symfony.com/blog/cve-2014-5244-denial-of-service-with-a-malicious-http-host-header>`_ (Symfony 2.3.19, 2.4.9 and 2.5.4)
-* July 15, 2014: `Security releases: Symfony 2.3.18, 2.4.8, and 2.5.2 released <https://symfony.com/blog/security-releases-cve-2014-4931-symfony-2-3-18-2-4-8-and-2-5-2-released>`_ (`CVE-2014-4931 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4931>`_)
-* October 10, 2013: `Security releases: Symfony 2.0.25, 2.1.13, 2.2.9, and 2.3.6 released <https://symfony.com/blog/security-releases-cve-2013-5958-symfony-2-0-25-2-1-13-2-2-9-and-2-3-6-released>`_ (`CVE-2013-5958 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5958>`_)
-* August 7, 2013: `Security releases: Symfony 2.0.24, 2.1.12, 2.2.5, and 2.3.3 released <https://symfony.com/blog/security-releases-symfony-2-0-24-2-1-12-2-2-5-and-2-3-3-released>`_ (`CVE-2013-4751 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4751>`_ and `CVE-2013-4752 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4752>`_)
-* January 17, 2013: `Security release: Symfony 2.0.22 and 2.1.7 released <https://symfony.com/blog/security-release-symfony-2-0-22-and-2-1-7-released>`_ (`CVE-2013-1348 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1348>`_ and `CVE-2013-1397 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1397>`_)
-* December 20, 2012: `Security release: Symfony 2.0.20 and 2.1.5 <https://symfony.com/blog/security-release-symfony-2-0-20-and-2-1-5-released>`_  (`CVE-2012-6431 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6431>`_ and `CVE-2012-6432 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6432>`_)
-* November 29, 2012: `Security release: Symfony 2.0.19 and 2.1.4 <https://symfony.com/blog/security-release-symfony-2-0-19-and-2-1-4>`_
-* November 25, 2012: `Security release: symfony 1.4.20 released  <https://symfony.com/blog/security-release-symfony-1-4-20-released>`_ (`CVE-2012-5574 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5574>`_)
-* August 28, 2012: `Security Release: Symfony 2.0.17 released <https://symfony.com/blog/security-release-symfony-2-0-17-released>`_
-* May 30, 2012: `Security Release: symfony 1.4.18 released <https://symfony.com/blog/security-release-symfony-1-4-18-released>`_ (`CVE-2012-2667 <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2667>`_)
-* February 24, 2012: `Security Release: Symfony 2.0.11 released <https://symfony.com/blog/security-release-symfony-2-0-11-released>`_
-* November 16, 2011: `Security Release: Symfony 2.0.6 <https://symfony.com/blog/security-release-symfony-2-0-6>`_
-* March 21, 2011: `symfony 1.3.10 and 1.4.10: security releases <https://symfony.com/blog/symfony-1-3-10-and-1-4-10-security-releases>`_
-* June 29, 2010: `Security Release: symfony 1.3.6 and 1.4.6 <https://symfony.com/blog/security-release-symfony-1-3-6-and-1-4-6>`_
-* May 31, 2010: `symfony 1.3.5 and 1.4.5 <https://symfony.com/blog/symfony-1-3-5-and-1-4-5>`_
-* February 25, 2010: `Security Release: 1.2.12, 1.3.3 and 1.4.3 <https://symfony.com/blog/security-release-1-2-12-1-3-3-and-1-4-3>`_
-* February 13, 2010: `symfony 1.3.2 and 1.4.2 <https://symfony.com/blog/symfony-1-3-2-and-1-4-2>`_
-* April 27, 2009: `symfony 1.2.6: Security fix <https://symfony.com/blog/symfony-1-2-6-security-fix>`_
-* October 03, 2008: `symfony 1.1.4 released: Security fix <https://symfony.com/blog/symfony-1-1-4-released-security-fix>`_
-* May 14, 2008: `symfony 1.0.16 is out  <https://symfony.com/blog/symfony-1-0-16-is-out>`_
-* April 01, 2008: `symfony 1.0.13 is out  <https://symfony.com/blog/symfony-1-0-13-is-out>`_
-* March 21, 2008: `symfony 1.0.12 is (finally) out ! <https://symfony.com/blog/symfony-1-0-12-is-finally-out>`_
-* June 25, 2007: `symfony 1.0.5 released (security fix) <https://symfony.com/blog/symfony-1-0-5-released-security-fix>`_
+Check the `Security Advisories`_ blog category for a list of all security
+vulnerabilities that were fixed in Symfony releases, starting from Symfony
+1.0.0.
 
 .. _Git repository: https://github.com/symfony/symfony
 .. _blog: https://symfony.com/blog/
 .. _Security Advisories: https://symfony.com/blog/category/security-advisories
 .. _`security advisories database`: https://github.com/FriendsOfPHP/security-advisories
 .. _`mitre.org`: https://cveform.mitre.org/
+.. _`Security Advisories`: https://symfony.com/blog/category/security-advisories

reference/constraints/NotBlank.rst

@@ -2,7 +2,7 @@ NotBlank
 ========
 
 Validates that a value is not blank - meaning not equal to a blank string,
-a blank array or ``null``::
+a blank array, ``null`` or ``false``::
 
     if (false === $value || (empty($value) && '0' != $value)) {
         // validation will fail

reference/forms/types/options/choice_attr.rst.inc

@@ -3,8 +3,9 @@ choice_attr
 
 **type**: ``array``, ``callable`` or ``string`` **default**: ``array()``
 
-Use this to add additional HTML attributes to each choice. This can be an array
-of attributes (if they are the same for each choice), a callable or a property path
+Use this to add additional HTML attributes to each choice. This can be
+an associative array where the keys match the choice keys and the values
+are the attributes for each choice, a callable or a property path
 (just like `choice_label`_).
 
 If an array, the keys of the ``choices`` array must be used as keys::

security/multiple_user_providers.rst

@@ -1,6 +1,12 @@
 How to Use multiple User Providers
 ==================================
 
+.. note::
+
+    It's always better to use a specific user provider for each authentication
+    mechanism. Chaining user providers should be avoided in most applications
+    and used only to solve edge cases.
+
 Each authentication mechanism (e.g. HTTP Authentication, form login, etc.) uses
 exactly one user provider. But what if you want to specify a few users via
 configuration and the rest of your users in the database? This is possible by
@@ -147,5 +153,25 @@ authentication system will use the ``in_memory`` user provider. But if the user
 tries to log in via the form login, the ``user_db`` provider will be used (since
 it's the default for the firewall as a whole).
 
+If you need to check that the user being returned by  your provider is a allowed
+to authenticate, check the returned user object::
+
+    use Symfony\Component\Security\Core\User;
+    // ...
+
+    public function loadUserByUsername($username)
+    {
+        // ...
+
+        // you can, for example, test that the returned user is an object of a
+        // particular class or check for certain attributes of your user objects
+        if ($user instance User) {
+            // the user was loaded from the main security config file. Do something.
+            // ...
+        }
+
+        return $user;
+    }
+
 For more information about user provider and firewall configuration, see
 the :doc:`/reference/configuration/security`.

service_container/3.3-di-changes.rst

@@ -568,6 +568,16 @@ Start by updating the service ids to class names:
     you can't redefine the service as ``Twig_Extensions_Extension_Intl: ~`` and
     you must keep the original ``class`` parameter.
 
+.. caution::
+
+    If a service is processed by a :doc:`compiler pass </service_container/compiler_passes>`,
+    you could face a  "You have requested a non-existent service" error.
+    To get rid of this, be sure that the Compiler Pass is using ``findDefinition()``
+    instead of ``getDefinition()``. The latter won't take aliases into
+    account when looking up for services.
+    Furthermore it is always recommended to check for definition existence
+    using ``has()`` function.
+
 But, this change will break our app! The old service ids (e.g. ``app.github_notifier``)
 no longer exist. The simplest way to fix this is to find all your old service ids
 and update them to the new class id: ``app.github_notifier`` to ``App\Service\GitHubNotifier``.

setup/_update_dep_errors.rst.inc

@@ -19,3 +19,11 @@ the issue.
 
 Or, you may have deeper issues where different libraries depend on conflicting
 versions of other libraries. Check your error message to debug.
+
+Another issue that may happen is that the project dependencies can be installed
+in your local computer but not on the remote server. This usually happens when
+the PHP versions are different on each machine. The solution is to add the
+`platform`_ config option in your `composer.json` file to define the highest
+PHP version allowed for the dependencies (set it to server's PHP version).
+
+.. _`platform`: https://getcomposer.org/doc/06-config.md#platform

setup/flex.rst

@@ -95,13 +95,8 @@ two public repositories:
 
 * `Contrib recipe repository`_, contains all the recipes created by the
   community. All of them are guaranteed to work, but their associated packages
-  could be unmaintained. Symfony Flex ignores these recipes by default, but you
-  can execute this command to start using them in your project:
-
-  .. code-block:: terminal
-
-        $ cd your-project/
-        $ composer config extra.symfony.allow-contrib true
+  could be unmaintained. Symfony Flex will ask your permission before installing
+  any of these recipes.
 
 Read the `Symfony Recipes documentation`_ to learn everything about how to
 create recipes for your own packages.

workflow/state-machines.rst

@@ -35,6 +35,7 @@ Below is the configuration for the pull request state machine.
                     type: 'state_machine'
                     supports:
                         - App\Entity\PullRequest
+                    initial_place: start
                     places:
                         - start
                         - coding

workflow/usage.rst

@@ -46,6 +46,7 @@ like this:
                             - 'currentPlace'
                     supports:
                         - App\Entity\BlogPost
+                    initial_place: draft
                     places:
                         - draft
                         - review