Open Ceremony64 opened 6 years ago
I can confirm and reproduce this issue with latest Typo3 version 8.7.17. I also agree that this issue is related to the mentioned bug reported here.
After scratching my head I guess that this problem arises because your extension uses extbase repository functions in https://github.com/WebentwicklerAt/typo3-loginlimit/blob/71c8ce1bbc1c982a0cad6dcba07b3f00e7d9161c/Classes/Service/CleanUpService.php#L126 prior to normal Typoscript template initialization in https://github.com/TYPO3/TYPO3.CMS/blob/353b5af8630e4167e07ae652cbb9bbb17d1d0761/typo3/sysext/frontend/Classes/Http/RequestHandler.php#L171
It turned out for me that the real cause is an (sometimes) empty Typoscript template which I found by utilising the proposed logging mechanism of Sander Leeuwesteijn here
There is an issue with this extension being active on my Typo3 8.7.16 instance: Typo3 tries to (sometimes) access non-existent tables upon login, ignoring the correct table mapping specified via TypoScript (via ext_typoscript_setup.txt). Once a user encounters the error, he'll be stuck and no refreshing can fix it. Only clearing the typo3 cache fixes the issue temporarily.
Example:
I have found this entry in the typo3 bugtracker which seems to point in the right direction. Overwriting the cache config for the extbase datamap to disable caching entirely, always produces login errors for me (set via AdditionalConfiguration.php):
With loginlimit extensions disabled, I get no more errors, with or without the extbase_datamapfactory_datamap cache disabled.
I am not sure if this issue occurs with "stock" typo3 v8.7.16. Please report back if you have issues reproducing this issue and I'll see if I can get a simplified typo3 setup up to test with...