Bug #20029
closedt3lib_div::makeInstanceClassName() allows to bypass checks for t3lib_Singleton
0%
Description
When marking a class as singleton by implementing t3lib_Singleton one can assure that at any time there's only one instance of that class when consistently using t3lib_div::makeInstance(). However, one can circumvent this and still create multiple instances of the class by using t3lib_div::makeInstanceClassName() together with the new operator.
The same problem arises when implementing t3lib_Singleton and requiring arguments to be passed to the constructor of that class. This class can only be instanciated by using t3lib_div::makeInstanceClassName() and the new operator, and thus again bypassing the check for the singleton.
This can have multiple implications with performance and also behavior.
Solution: * make t3lib_div::makeInstance() aware of constructor arguments in the first step.- make the functionality of t3lib_div::makeInstanceClassName() available as a protected internal function. This functionality is still needed to recursively resolve xclassed class names.
- mark t3lib_div::makeInstanceClassName() as deprecated with a hint for t3lib_div::makeInstance()
- replace all occurances of t3lib_div::makeInstanceClassName() in the core with t3lib_div::makeInstance() calls. (separate issue)
- later, with TYPO3 4.5, remove t3lib_div::makeInstanceClassName() eventually enforcing the check for singletons
The last hunk in the patch acts as an example of how the code is cleaned up and still works. This is not part of the actual patch and is not intended for the commit.
We can of course not prevent someone from directly using the new operator with the class name, but this is out of scope for this issue as it's considered unclean anyways as xclasses aren't taken into account this way.
(issue imported from #M10454)
Files
Updated by Ingo Renner almost 16 years ago
v2 handles an error that is raised when trying to use $reflectionObject->newInstanceArgs($constructorArguments); on a class that does not have a constructor. That case should be rare though. For performance reasons we ignore it for now and keep the patch here just in case.