[TASK] Use /index.php as application entry point #533
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bnf
force-pushed
the
streamline-entry-points-v6
branch
from
ef05d35
to
2073a91
Compare
|
quick view/first impression: we need to make this conditional based to ensure working with v12 (state before change) and v13 (with changed entrypoints) - or start breaking the 1 TF version 2 core version support away, which I would try to avoid as this will get a huge cry in the community and extension developers. |
|
Hmpf.... Current state is a huge mess for us developers and results in ugly code all over the place (For example all that outdated code in Providing API compatibility for two versions might be fine, but that doesn't mean one TestingFramework version needs to support multiple TYPO3 versions. Extension authors can simply require-dev Note: I also want to refactor other stuff like the initialization with So please enlighten me on why we can't simply release TF v9 with the same API as v8? |
bnf
force-pushed
the
streamline-entry-points-v6
branch
2 times, most recently
from
24263aa
to
8a1fcd4
Compare
I've now added such conditions for v12 compat and tested on current 12.4 and main via:
I still think we should do the split versions with focus on merging TF into core, but I'll discuss that when we've got more time for such things. |
|
I'm fine with the change as is. @sbuerk ? |
bnf
changed the title
/typo3/index.php is deprecated and must not longer be used as of https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366 Releases: main Resolves: https://forge.typo3.org/issues/87889
bnf
force-pushed
the
streamline-entry-points-v6
branch
from
8a1fcd4
to
37e45b7
Compare
|
tl;dr: Patch looks good, especially with https://review.typo3.org/c/Packages/TYPO3.CMS/+/82595 being green. About versioning: The reason for TF supporting two core versions: This guarantees API compatibility for extensions, which is kinda convenient for extension authors. It also forces TF maintainers to think about compat layers. We basically have a triangle between extension<->TF-api<->core-api here. In case of this patch TF<->core is affected, which forces us to have TF compat at this point to keep extension<->TF clean. Note I'd love to see a TF core-monorepo merge as well, but this needs a bit of additional infrastructure since monorepo currently can't host casual composer packages. When we merge at some point, we could review the compat problematic along the way. |
lolli42
approved these changes
Jan 23, 2024
| @@ -55,21 +55,21 @@ public function useExistingSession(string $role, float|int $waitTime = 0.5) | |||
|
|
|||
| $hasSession = $this->_loadSession(); | |||
| if ($hasSession && $newUserSessionId !== '' && $newUserSessionId !== $this->getUserSessionId()) { | |||
| $webDriver->amOnPage('/typo3/index.php'); | |||
| $webDriver->amOnPage('/typo3'); | |||
There was a problem hiding this comment.
those are ok due to v12 / web server redirects.
| @@ -496,15 +497,20 @@ private function createServerRequest(string $url, string $method = 'GET'): Serve | |||
| { | |||
| $requestUrlParts = parse_url($url); | |||
| $docRoot = $this->instancePath; | |||
|
|
|||
| // @todo: Remove when dropping support for v12 | |||
| $hasConsolidatedHttpEntryPoint = class_exists(CoreHttpApplication::class); | |||
There was a problem hiding this comment.
that's a simple and straight b/w compat detection strategy. fine with me. and it's smart since v13 core without the entry-point patch does not fail (which would happen when going for a typo3Version check).
| ); | ||
| // @todo: Remove when dropping support for v12 | ||
| $hasConsolidatedHttpEntryPoint = class_exists(CoreHttpApplication::class); | ||
| if (!$hasConsolidatedHttpEntryPoint) { |
There was a problem hiding this comment.
So good to see this gone in v13!
sbuerk
approved these changes
Jan 23, 2024
|
thx! |
reviewtypo3org
pushed a commit
to TYPO3/typo3
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/backend
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/core
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/extbase
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/fluid
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/frontend
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/indexed_search
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
TYPO3IncTeam
pushed a commit
to TYPO3-CMS/install
that referenced
this pull request
Jan 24, 2024
The TYPO3 Backend URL is made configurable in order to enable optional
protection against application admin interface infrastructure
enumeration (WSTG-CONF-05). Both, frontend and backend requests are
now handled by the PHP script `/index.php` to enable virtual admin
interface URLs.
The default TYPO3 Backend entrypoint path `/typo3` can be changed by
specifying a custom URL path or domain name in
`$GLOBALS['TYPO3_CONF_VARS']['BE']['entryPoint']`.
This change requires web server adaption. A silent migration and
according documentation for custom web server configurations is added.
A deprecation layer (for non-adapted systems) is in place that rewrites
the server environment variables passed to `/typo3/index.php` as if
`/index.php` was used directly. This layer will be removed in TYPO3 v14.
This change does not take assets into account, only routing is adapted.
That means composer mode will use assets provided via _assets as before
and TYPO3 classic mode will serve backend assets from /typo3/* even if
another backend URL is used and configured.
In composer mode there is an additional opt-out for the installation of
the legacy entrypoint for that can be defined in composer.json:
"extra": {
"typo3/cms": {
"install-deprecated-typo3-index-php": false
}
}
The application flow is slightly adapted by moving common middlewares
into a separate core middleware chain. This chain is dispatched by a
distinct core HTTP application (which is invoked by index.php).
These middlewares are suitable for proxy determination or generic
access control – basically everything not needed for subrequests.
The core HTTP request handler then decides whether the request is to be
routed to the frontend or backend application. Frontend and backend
appplications are still designed to work independently with a plain
PSR-7 Server Request in order for sub requests from backend to frontend
(or vice versa) to work.
The following diagram outlines the new application workflow including
flow of possible sub requests (not yet used from backend to frontend,
but it shows how they are intended to be invoked):
+-------------------+
| |
| Core HTTP |
| Application |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
| Middlewares |
| |
+---------+---------+
|
|
v
+---------+---------+
| |
| Core HTTP |
+-------------+ Request Handler +--------------+
| | | |
| +-------------------+ |
| |
v v
+--------+----------+ +---------+---------+
| | (Sub Request) | |
| Frontend HTTP +<-------------+ | Backend HTTP |
| Application +<-----------+ | | Application |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Middlewares | | | | Middlewares |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| Frontend HTTP | | | | Backend HTTP |
| Request Handler | | | | Request Handler |
| | | | | |
+---------+---------+ | | +---------+---------+
| | | |
| | | |
v | | v
+---------+---------+ | | +---------+---------+
| | | | | |
| TypoScript | | | | Backend Route |
| Frontend +------------+ | | Dispatcher |
| Controller | | | |
| | | +---------+---------+
+-------------------+ | |
| |
| v
| +---------+---------+
| | |
| | Backend |
+------------+ Controller |
| |
+-------------------+
Commands executed:
# For changed in TYPO3/testing-framework#533
composer req --dev "typo3/testing-framework":"dev-main"
Resolves: #87889
Releases: main
Change-Id: I3c96d4d7c58f08ed302ee35eb75d28afbf77686a
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Reviewed-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: core-ci <typo3@b13.com>
Tested-by: Stefan Bürk <stefan@buerk.tech>
Tested-by: Christian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Christian Kuhn <lolli@schwarzbu.ch>
Tested-by: Oliver Hader <oliver.hader@typo3.org>
Reviewed-by: Benni Mack <benni@typo3.org>
Tested-by: Benni Mack <benni@typo3.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
/typo3/index.php is deprecated and must not longer be used.
See https://forge.typo3.org/issues/87889 and
https://review.typo3.org/c/Packages/TYPO3.CMS/+/74366
Releases: main