Skip to content
GitLab
  1. 15 Jun, 2022 1 commit
  3. 14 Jun, 2022 1 commit
  5. 17 Nov, 2021 1 commit
  7. 16 Nov, 2021 1 commit
  9. 05 Nov, 2021 1 commit
  11. 07 Dec, 2020 1 commit
  13. 16 Nov, 2020 1 commit
  15. 07 Sep, 2020 1 commit
  17. 04 Sep, 2020 1 commit
  19. 12 May, 2020 1 commit
  21. 17 Apr, 2020 1 commit
  23. 15 Apr, 2020 1 commit
  25. 14 Apr, 2020 2 commits
  27. 17 Feb, 2020 1 commit
  29. 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
  31. 11 Dec, 2018 1 commit
  33. 01 Oct, 2018 1 commit
  35. 30 Jul, 2018 1 commit
  37. 29 May, 2018 1 commit
  39. 29 Mar, 2018 1 commit
  41. 09 Feb, 2018 1 commit
  43. 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
  45. 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
  47. 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
  49. 23 Aug, 2017 1 commit
  51. 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
  53. 26 Feb, 2017 1 commit
  55. 30 Aug, 2016 2 commits
  57. 19 Feb, 2016 1 commit
  59. 12 Jan, 2016 1 commit
  61. 08 Oct, 2015 1 commit
  63. 15 Jul, 2015 1 commit
  65. 01 Jul, 2015 1 commit
  67. 19 Feb, 2015 1 commit
  69. 16 Dec, 2014 1 commit
  71. 13 Dec, 2014 1 commit
  73. 03 Nov, 2014 1 commit
  75. 02 Nov, 2014 1 commit