301c659 breaks 11LTS-compatibility due to wrong group table lookup

[J. Peter M. Schuler]

With dev-master I had the problem that although group sync was disabled and keep be groups was enabled, my users be_groups were manipulated (not all groups retained, only some).
Found out that the SQL query for checking the groups referred to the wrong table:

t3ext-ig_ldap_sso_auth/Classes/Domain/Repository/Typo3UserRepository.php

Line 376 in 785ade1

 public static function setUserGroups(array $typo3User, array $typo3Groups, string $table): array 

creates an SQL query referring to the wrong table.
Called by

t3ext-ig_ldap_sso_auth/Classes/Library/Authentication.php

Line 257 in 785ade1

 $typo3_user = Typo3UserRepository::setUserGroups($typo3_user, $typo3_groups, $groupTable); 

However the table here was fe_groups, thus the chaos. So somehow the new implementation of

t3ext-ig_ldap_sso_auth/Classes/Library/Authentication.php

Lines 917 to 928 in 785ade1

 protected static function getGroupTable(): string 
 { 
     if (isset(static::$authenticationService) && !empty(static::$authenticationService->authInfo['db_groups']['table'])) { 
         $groupTable = static::$authenticationService->authInfo['db_groups']['table']; 
     } else { 
         if (CompatUtility::getTypo3Mode() === 'BE') { 
             $groupTable = 'be_groups'; 
         } else { 
             $groupTable = 'fe_groups'; 
         } 
     } 
     return $groupTable; 

is not correct for 11LTS

333c92f is the version before that, which works fine in that regard - and not deep enough in 12LTS to provide a fix, but thought to at least mention the bug

[PitScribble]

I had the same problem with dev-master in TYPO3 v11.5, but was not able to find the reason, but what you write seems reasonable. For me groups keep getting deleted form be_users even tho i have disabled group syncing and with 3.7.1 this was not a problem.

[chrosey]

having the same issue with TYPO3 11.5
in my case Library/Authentication.php has neither static::$authenticationService or $GLOBALS['TYPO3_REQUEST'] available. Then it assumes fe_groups is the right table.

My Workaround for TYPO3 11 is this patch:

diff --git a/Classes/Utility/CompatUtility.php b/Classes/Utility/CompatUtility.php
--- a/Classes/Utility/CompatUtility.php	
+++ b/Classes/Utility/CompatUtility.php	(date 1688549974000)
@@ -33,6 +33,7 @@
                     ? 'FE'
                     : 'BE';
             }
+            if (defined('TYPO3_MODE')) return TYPO3_MODE;
             // Hopefully TYPO3 v12 will always provide a valid TYPO3_REQUEST, and we
             // won't have to have some magic in the calling method
             return null;