Project

General

Profile

Actions

Feature #62742

closed

TCA schould always be loaded early

Added by Tizian Schmidlin over 9 years ago. Updated almost 9 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-11-06
Due date:
% Done:

0%

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

Description

First, a bit of history, to know where I go:

.h2 History

Today I encountered a problem while working on a login service for an application using TYPO3 6.2 and Extbase.

My login service relies on a REST Repository of my own, that allows me to get data from a REST interface somewhere in my cloud. This always worked fine with TYPO3 4.7.7 and 4.7.17 but with the update to 6.2.5, a strange behaviour occured: the cached Datamap Objects were empty!

So I got down on my knees ans shoveld for some hours to get to the place where the magic happens: the DataMapperFactory. As expected, the fields and everything got parsed correctly by the DocCommentParser and the information was stored as expected by it. But what then happened was strange. Very strange: the tcaDefaultConfigs for the table was empty.

Long story short: at the point where my login service wanted to access my RESTCallModel for the first time, no TCA was loaded at all, therefore making a mapping of the fields from the TCA to the fields of the object impossible!

I've tried several things like force-loading the TCA or just don't cache the datamaps, but this didn't solve the problem, since for the first, other errors appeared that and the second didn't solve the problem at all, since at the point where I needed the dataMapper there would be any TCA ever.

I was able to solve the problem by first checking if a cached DataMapper for my object existed and then silently fail to log in, so that the object isn't called until the TCA is first loaded.

This is kind of an ugly way to do this and I'm not very proud of that hack but at least it works.

.h2 The point

It would be great to have TCA loaded for the login services since it impossible to properly load an object from the repository if it wasn't already cached due to missing TCA definitions at the point where the DataMapperFactory has to build the DataMapper object for a model.


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #62853: Caching datamaps within eID-requests results in incomplete cache entriesRejected2014-11-11

Actions
Related to TYPO3 Core - Bug #68106: cf_extbase_datamapfactory_datamap created wrong with sys_categoriesClosed2015-07-14

Actions
Actions #1

Updated by Frederic Gaus over 9 years ago

I can confirm this issue. Cost a lot of time to find the reason. I would suggest to change this from [FEUTURE] to [BUGFIX]!

Actions #2

Updated by DMK E-BUSINESS GmbH about 9 years ago

I can confirm this too. I'm having this problem with the extension felogin_bruteforce_protection.

@see https://github.com/AOEpeople/felogin_bruteforce_protection/issues/2

Actions #3

Updated by Stefan Masztalerz about 9 years ago

At the point of the postUserLookUp-Hook (['t3lib/class.t3lib_userauth.php']['postUserLookUp']) the TCA is not loaded.
What would be the correct way to load the TCA when needed in the hook, due to the fact that the loadTCA-Function doesn't exist anymore?

Also: the related fix for Bug #62853 won't fix that problem because they asume that the TCA is allways loaded when not entering by eID.

Confirmed with: TYPO3 6.2.10 - clean introduction package
Also would suggest to change this to [BUGFIX]!

Actions #4

Updated by Christian Kuhn almost 9 years ago

  • Status changed from New to Rejected

Hey.

Thanks for your reports and the analysis of this problem.

The main problem here is that extbase is prepared as a full-fledged application on top of the fully initialized framework. If you try to hook extbase into early bootstrap phases - like in your case using the authentication process - the problem is that lots of information that extbase requires does not exist yet. This not only affects the TCA stuff. Extbase for example also depends on initialized TypoScript to have the configuration and injection information at hand, and also on a resolved page id. All this is not the case at this early stage and it can fail at any point.

Basically, if you still decide to use extbase for such low level stuff, it is up to the developer to take care of proper initialization and it can also happen that this stuff breaks during core version upgrades.

This situation will not change anytime soon and there is little chance to have a fully supported extbase framework available in the future for this or other related hooks.

I'm sorry, but there is no other way than closing this issue with 'won't fix' for the time being.

Actions

Also available in: Atom PDF