Project

General

Profile

Actions

Feature #104383

open

Better error messages for “Validation failed while trying to call …Controller->detailAction()”

Added by Bernhard Eckl 3 days ago. Updated 3 days ago.

Status:
Needs Feedback
Priority:
Could have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2024-07-12
Due date:
% Done:

0%

Estimated time:
PHP Version:
8.2
Tags:
Complexity:
Sprint Focus:

Description

Sometimes it is really hard to find out the problem itself when extbase only says “Validation failed while trying to call …Controller->detailAction()” and nothing more in TYPO3 log file. So why not tell the developer which validation fails?

Actions #1

Updated by Garvin Hicking 3 days ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Needs Feedback
  • Priority changed from Should have to Could have
  • TYPO3 Version deleted (11)

What kind of extension/action setup/workflow do you use here, where you could need more information?

From what I understand, the message is intentionally meant vague, because it's revealed to consumers and should not carry possibly security-relevant information about the internal application. I believe it should only happen when an extbase action validation fails, which should only happen with malformed requests. If you want to reveal the errors, you might want to override the errorAction in your extbase controller and return a custom error template, revealing the flashmessages. Or you could instead use model validation instead of action validation to get more granular control over what kind of errors on models get reported?

You might also be able to use a custom errorAction() to read the flashmessages and forward them to a logger. The current extbase default errorAction implementation is also intentionally very basic ("This is suitable for most actions dealing with form input") so I'm not sure if it can be enhanced easily fit extended needs. For other people, extra info on "wrong use" of bots of extbase acctions being logged might significantly spam the logging facilities, so it's not easy to make it suitable for everyone.

Maybe for Staging/Development context this could be changed to directly put the flash message contents into the htmlResponse, would that help for your scenario?

Actions

Also available in: Atom PDF