1. 15 Jun, 2022 1 commit
  2. 14 Jun, 2022 1 commit
  3. 17 Nov, 2021 1 commit
  4. 16 Nov, 2021 1 commit
  5. 05 Nov, 2021 1 commit
  6. 07 Dec, 2020 1 commit
  7. 16 Nov, 2020 1 commit
  8. 07 Sep, 2020 1 commit
  9. 04 Sep, 2020 1 commit
  10. 12 May, 2020 1 commit
  11. 17 Apr, 2020 1 commit
  12. 15 Apr, 2020 1 commit
  13. 14 Apr, 2020 2 commits
  14. 17 Feb, 2020 1 commit
  15. 13 Feb, 2020 1 commit
    • Benni Mack's avatar
      [FEATURE] Implement SameSite option for TYPO3 cookies · de29dc2d
      Benni Mack authored and Georg Ringer's avatar Georg Ringer committed
      This change introduces a new security option for setting the SameSite
      option to all cookies sent by TYPO3 Core.
      
      Namely:
      - Frontend User Sessions ("lax" by default)
      - Backend User Sessions ("strict" by default)
      - Install Tool Sessions ("strict", none-configurable)
      - Last Login Provider in Backend ("strict", non-configurable)
      
      This means that these can only be accessed by scripts and requests
      by the same site, and not by any third-party scripts.
      
      Since we're talking about actual cookies for a user, and not
      ads-related or third-party login-dependant cookies, the default
      options fit just perfectly.
      
      All modern browsers except Internet Explorer respect this option
      to be set. Please note that Firefox and Chrome will have "SameSite=lax"
      set in Q1/2020 by default if NO SameSite option is set at all. This change
      allows to configure this.
      
      Backend and Frontend User Cookies can be configured to "strict", "lax"
      or "none" (= same as before), whereas "none" only works for secure
      connections (= HTTPS).
      
      If "strict" is in place, security via CSRF is not needed anymore, and can
      be dropped in the future.
      
      Resolves: #90351
      Releases: master, 9.5, 8.7
      Change-Id: I8095e2a552faa9d1fd4fa7855297302a9ec6a75f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/63183
      
      
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      de29dc2d
  16. 11 Dec, 2018 1 commit
  17. 01 Oct, 2018 1 commit
  18. 30 Jul, 2018 1 commit
  19. 29 May, 2018 1 commit
  20. 29 Mar, 2018 1 commit
  21. 09 Feb, 2018 1 commit
  22. 19 Sep, 2017 1 commit
    • Christian Kuhn's avatar
      [TASK] Install tool: JS driven routing · 3896e163
      Christian Kuhn authored and Susanne Moog's avatar Susanne Moog committed
      The install tool suffered from three main issues since 6.2 rewrite:
      * The "step" installer was re-used for recovery and installation
      * The routing logic was server based and threw lots of redirects
        which lead to redirect loops
      * The Controller/Action class structure was weird and hard to
        understand
      
      The patch solves this with a rather huge rewrite:
      * There are two request handlers: One for the Installer, one for
        the install tool.
      * A simple list of controllers. One InstallerController for the
        step installer, the others for the main module points of the
        install tool and a Login and a Layout controller.
      * Single action code is moved into controllers.
      * Both tool and installer first load only a <head> section that
        contain JS references. All other calls are ajax based and the
        routing is done JS side.
      * Installer and install tool no longer share controller code
        or templates, the installer can potentially be fully extracted
        from ext:install in another step.
      * Installer.js is the "walk through installation" module of the
        installer.
      * Router.js is the routing module for the install tool, all tool
        ajax requests get specific urls from this module and hand over
        errors to the Router.
      * Error handling is handled on JS side: If for instance
        the login session expires and user clicks elsewhere, a 403
        response is returned which is handled by JS to route to login.
        This is also the place where a recovery can hook in later.
      * The silent configuration updater is executed again which was
        removed during one of the previous master patches.
      * The template structure is much easier.
      * Various card content which has been calculated when loading
        the card layout is moved to the ajax code for single card
        content. That increases the performance of the main module
        points and makes them pretty snappy.
      
      Change-Id: Ib40f40acba17bb47142c0da1bcfb389ab9b4b3a1
      Resolves: #82504
      Releases: master
      Reviewed-on: https://review.typo3.org/54128
      
      
      Tested-by: default avatarStefan Neufeind <typo3.neufeind@speedpartner.de>
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Tested-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      3896e163
  23. 11 Sep, 2017 1 commit
    • Christian Kuhn's avatar
      [BUGFIX] Install tool: Use standalone application in backend context · e7cc537f
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      With recent routing changes the install tool "backend context" has
      been switched to a "normal" backend module loaded directly from
      within the backend application. The standalone is an own application
      with its own bootstrap.
      This leads to various issues in the install tool since the backend
      and standalone requests lead to different bootstrap states, for
      instance TCA is initialized in BE context, but isn't in standalone.
      Within backend, this won't change until the backend application can
      bootstrap to different states depending on a controller.
      To solve install tool related issues for now, the BackendModuleController
      of the install tool called from within backend now starts a casual
      install tool session and marks this session as "initiated from a
      valid system maintainer". It then redirects to the standalone
      application which omits login and enable install tool file check if
      the session is marked as backend user session.
      
      Change-Id: I352e6d04e7a91c56ccf2383f784ae94464c9aacd
      Resolves: #82448
      Related: #82306
      Releases: master
      Reviewed-on: https://review.typo3.org/54111
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      e7cc537f
  24. 31 Aug, 2017 1 commit
    • Christian Kuhn's avatar
      [TASK] Install tool: Use ext:core messaging · aed46d2a
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      The install tool brought its own "status message" class
      structure since the 6.2 refactoring. This is used at many
      places in the install tool for message handling.
      
      The core has a very similar class construct "Messaging"
      with only little dependencies, too. To simplify a later
      separation of 'install tool' and 'installer' the internal
      status message class structure is removed and transitioned
      to the core Messaging structure. to get rid of just
      another special thing the install tool does.
      
      The ext:core FlashMessage and FlashMessageQueue now both
      implement the \JsonSerialize interface. This allows direct
      json_encode() calls on these objects, helpful for instance
      for ajax responses.
      
      In ext:install "Environment checks" suhosin specific checks
      have been removed since the project is dead and only has a
      pre-alpha php 7.0 fork, so probably nobody is using
      that with the given core PHP constraints anymore.
      
      Change-Id: Ifecd3cd4889d8db5aaf3e87f317c98be706ae82b
      Resolves: #82257
      Releases: master
      Reviewed-on: https://review.typo3.org/53835
      
      
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Frank Nägler's avatarFrank Naegler <frank.naegler@typo3.org>
      Tested-by: Frank Nägler's avatarFrank Naegler <frank.naegler@typo3.org>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      aed46d2a
  25. 23 Aug, 2017 1 commit
  26. 28 Mar, 2017 1 commit
    • Wouter Wolters's avatar
      [TASK] Streamline return tags in phpdocs · eb049dba
      Wouter Wolters authored and Benni Mack's avatar Benni Mack committed
      The TYPO3 Core currently has no guidline how to handle phpdoc
      comments regarding @return annoations related to "void" and "null".
      
      In practice, these annotations have no additional value if no additional
      documentation is given.
      
      With this change, the php-cs-fixer will remove any unnecessary linebreaks
      within the comments above the @return annotation, as well as remove completely
      empty phpdoc comments because the @return annotation is removed.
      
      Please be aware, that once PSR-5 is accepted, this coding standard
      within the TYPO3 Core will change again, where there are currently
      some further proposal details like inheritance information.
      
      Resolves: #80454
      Releases: master
      Change-Id: Ie969d720684c0a75919fe5addd1c36ef5b12eb04
      Reviewed-on: https://review.typo3.org/51686
      
      
      Reviewed-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Tested-by: Nicole Cordes's avatarNicole Cordes <typo3@cordes.co>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      eb049dba
  27. 26 Feb, 2017 1 commit
  28. 30 Aug, 2016 2 commits
  29. 19 Feb, 2016 1 commit
  30. 12 Jan, 2016 1 commit
  31. 08 Oct, 2015 1 commit
  32. 15 Jul, 2015 1 commit
  33. 01 Jul, 2015 1 commit
  34. 19 Feb, 2015 1 commit
  35. 16 Dec, 2014 1 commit
  36. 13 Dec, 2014 1 commit
  37. 03 Nov, 2014 1 commit
  38. 02 Nov, 2014 1 commit