TYPO3 workspace preview not working with forms and HTTP POST data

Question

The following question has been asked in the #typo3-cms Slack channel:

A customer of us wants to use the workspaces feature. Thats working fine. But he cannot test his forms because workspaces are not supporting POST requests. (POST requests are incompatible with keyword preview), does anyone have an idea how to make plugins which are working with POST method testable in workspaces or any other workaround?

Answer 1

Explanation of the scenario and behavior

The check to prevent HTTP POST requests from being executed points back to TYPO3 CMS 4.0 in 2006 when the workspaces feature was introduced into TYPO3 (see accordant Git revision from back then).

Since the workspaces preview link initializes a backend user in an untrusted application context, the check has been used to prevent administration actions from being executed - today one would do that differently and use XSRF protection tokens for that.

The handling of these workspace preview links also was part of a security issue in sprint 2016 with the aim to remove possible security side effects in that regard further (see TYPO3-CORE-SA-2016-012 for details).

There are several possibilities to preview workspace changes:

Preview link from workspace module

In the top-bar of the workspace module in the TYPO3 backend, the preview link can be send to other parties that don't have credentials to access the TYPO3 backend. This mechanism basically leads to the problems with HTTP POST as mentioned above.

This behavior is implemented in the class PreviewHook in either the system extension version (up to and including TYPO3 CMS 7) or workspaces (since and including TYPO3 CMS 8). There's currently no easy way to by-pass the HTTP POST check, except granting possible previewers real and limited access to the TYPO3 backend with a valid user account.

Preview contents directly from page module

Editors that have access to the TYPO3 backend should use the regular preview mechanism of TYPO3 in the page module - this is the same for live versions and workspace changes. The only difference if working in a workspace is, that the website frontend shows additional workspace related widgets to compare changes.

Using this mechanism, the HTTP POST problems mentioned in the beginning of this answer don't occur and e.g. forms can be used without any limitations.

If the previous method of creating the workspace preview link has been used with the same browser already, a cookie ADMCMD_prev has been created which still triggers the preview link behavior and still leads to problems with HTTP POST - even if the regular preview mechanism is used as described in this section. To circumvent that, this cookie has to be cleared manually in the browser.