Feature #104383
openBetter error messages for “Validation failed while trying to call …Controller->detailAction()”
0%
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?
Updated by Garvin Hicking 7 months 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?
Updated by Garvin Hicking about 1 month ago
- Status changed from Needs Feedback to Closed
I'm closing this due to lack of feedback. If you feel this is a mistake please follow up with more details. Thank you!
Updated by Bernhard Eckl 11 days ago
- Status changed from Closed to New
Sorry for my late. In my case there was a validation which failed but I could not find which validation fails. There was no specific text to know which validation fails in the logs and also not in frontend. So information about which validation fails would be better instead of just that validation fails.
Updated by Garvin Hicking 11 days ago
- Status changed from New to Needs Feedback
Can you still reproduce this to work from there? In this case enabling the debug mode should give some help.
As mentioned, some validation message outputs need to be "vague" in order to prevent information disclosure, so we'll need to see how/if some middleground could be achieved.
Updated by Bernhard Eckl 10 days ago
It’s a long time ago and I already fixed it. If I remember right I think debug mode didn’t help. I can’t see any security issues if validation of a field fails, instead the user should know which validation fails. No matter, any hint about what’s wrong somewhere (logs, frontend) would be good. And as I remember I checked the source code where only exception with that message throws.
Updated by Garvin Hicking 10 days ago
Alright!
To proceed though, it would be very helpful to have an actual code example where the problem surfaces. Would you be able to provide this?
Updated by Bernhard Eckl 9 days ago
As I mentioned I already fixed the problem. I think it was a wrong date format for a configured date field or it was wrong type and type converter could not convert it (e.g. string -> array).
The source of the error message should be in function getFlattenedValidationErrorMessage there:
grep -rHn 'Validation failed while trying to call'
./cms-extbase/Classes/Mvc/Controller/ActionController.php:672: $outputMessage = 'Validation failed while trying to call ' . static::class . '->' . $this->actionMethodName . '().' . PHP_EOL;
But in getFlattenedValidationErrorMessage there is no further explanation about what validation exactly fails.