AOEpeople/felogin_bruteforce_protection

TCA not loaded

hannesbochmann opened this issue · 20 comments

I installed the extension in the version 0.4.2 but the bruteforce protection is not working as the entries in the database table for the domain models are inserted empty. So the extension doesn't recognize me as the same user and increments not the failure count.
This is because the TCA array is empty when the hook checks the login.
Have you experienced similar problems or is there likely a problem with my TYPO3 installation?

I'm wondering if this could work at all without loading the TCA. At least the login is checked before the TCA is loaded by TYPO3.
Furthermore the sys_page is not set in the TSFE leading to problems when writing to the database. The sys_page is first set when determineId is called in index_ts.php. This happens after handling the login, too.

Hi Hannes,

The client identifier is calculated from the user IP, not from the username. So the protection does not work on a username level, blocking an IP address.

I am not sure what you mean that the TCA is empty. Is it completely empty or fe_users / tx_feloginbruteforceprotection_domain_model_entry is missing? Please clarify. We had not issues so far with an empty TCA.

Nevertheless, we will release a newer version soon (v. 1.1.0 as on github) with better logging functionality.

Thanks for your report.

The TCA is completely empty. No table is configured as the TCA is not loaded at this moment.
I will test it in a fresh environment and try the new version from github.

I just made a fresh install of a TYPO3 site including felogin_bruteforce_protection as the only extension. Now when I login with wrong credentials in the frontend the same thing happens. All entries in the database table tx_feloginbruteforceprotection_domain_model_entry have no values but 0 or an empty string which causes the extension not to function as no attacks are recognized. This is because the TCA is not loaded when the entries are written.

Which TYPO3 version are you using?
We are not able to reproduce this error with our TYPO3 6.2 version

It's a clean TYPO3 6.2.9 install on a Ubuntu Linux with the current master branch version.

We will try to replicate your issue on a clean TYPO3 installation and will get back to you as soon as we know more. Thanks!

I managed to reproduce the bug.

Also i managed to fix this bug up to the point where the first call creates a correct record!
(partialy I used the patch of Frederic Gaus https://review.typo3.org/#/c/33980/)
Unfortunately now I have the problem that the record isn't recognised by the second wrong login.

You found a very strange TYPO3 Core Bug here... and I wonder why we're not facing the same problem.

Please verify the fix for your project

Unfortunately I can't confirm the bugfix to be working. The constructor of Aoe\FeloginBruteforceProtection\Domain\Repository\Entry is never called. Can you tell me when this should happen?
Even if I move your bugfix to the hook so it's definitely called, the entries in the database are inserted empty. The TCA gets loaded but that seems to change nothing. But this would mean that the TCA is cleared between the hook and the actual inserts into the database. This seems strange.

I investigated a little bit further. The datamap for the database table that is built by extbase is built before the hook PostUserLookUp is called. TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapFactory::buildDataMap is the point to look at. The TCA must be loaded before this is called.

Usally the DataMapper should only be called when trying to access a persited object or create one that possibly could.

For my freshly installed introduction package it works fine. So i'm very confused that the fix doesn't work for you... That the constructor of the entry repository is never called confuses me even more?!

Are you sure that you cleared the datamapper cache?

Okay, that did the trick. But now I have the same problem as you. The first wrong login is written to the database. The second wrong login causes the following error:
Call to a member function versionOL() on a non-object in .../typo3/sysext/extbase/Classes/Persistence/Generic/Storage/Typo3DbBackend.php on line 817
So the sys_page is not set in the TSFE.
Can you confirm that?

Yes had the same issue. solution: remove the filecache under /typo3temp/Cache/*
and clear all system caches (red flash - needs to be enabled in the installtool).
The caches of TYPO3 6.2 can be a little bit annoying...

Okay, I cleared all possible caches (all tables in the database with cf_* or cache*, typo3temp/Cache, the general, frontend and system cache in the BE) and now I'm stuck again with the problem of having all entries been written empty to the database.
I think I'm going to write my own extension providing a bruteforce protection.
But thanks for your efforts.

Tried it in a project with latest TYPO3 6.2.12. Neither the last git release nor current master work. Devlog reports correct values but database gets empty records like hannesbochmann reported. All necessary caches are cleared. Getter/Setter are called correctly, but your last fixes are never reached. Constructor is not called at all. Do you have any hint what can cause this problem ?

@verdure-peuser Thanks for your input. We will reopen this issue and look into it as soon as we find some time. Of course, any help from you would be greatly appreciated.

In that early point of processing authentication services TYPO3 is not fully loaded. The problem was produced by missing TCA and TSFE parts while processing the authentication service.

Now all needed TCA and TSFE parts will be loaded!