Status for TYPO3 v11

[xperseguers]

To make it clear: support for v11 is ongoing.

Please test this git repository and report problems if anything is found.

There are currently no planned release. Development on this project is based on free time as not currently in need of support for TYPO3 v11. Feel free to suggest sponsoring if you need some more reactive work on it.

Thanks.

[afle]

For us it's very important since we are planning to upgrade all our TYPO3 installations to version 11. What are the options for support/sponsoring you to finish this feature? PayPal.Me is not working at our company.

Currently version 3.7-dev is not working on TYPO3 v11.5.10.

[xperseguers]

Just tested both backend and frontend authentication in v11 and it worked for me.

Currently version 3.7-dev is not working on TYPO3 v11.5.10.

Maybe describe what is not working...

[afle]

You have to import users manually, otherwise log message: Login-attempt from x.x.x.x, username '<usernam>' not found!

If imported, logon is not possible: Login-attempt from x.x.x.x, username '<username>', no suitable hash method found!

What surprises me: column _be_users.tx_igldapssoauthdn is empty even when imported the users.

[xperseguers]

That's the result of using the demo LDAP server depicted in the documentation, with latest master branch and TYPO3 v11 (be_users):

When I configure the extension to allow users not yet imported (backend.TYPO3BEUserExist) and delete (!) every LDAP-related row and try again with newton/password, I just found a PHP warning which I fixed and will debug why (I can reproduce) an not yet-imported user cannot actually log in as you found. However, imported users work fine for me.

[xperseguers]

somehow the auto-created be_user is marked as "disabled", thus cannot authenticate!

[afle]

That's a user we imported manually, since it wasn't done by the extension:

 select * from be_users \G;
                 uid: 8
                 pid: 0
              tstamp: 1653912255
              crdate: 1653912255
           cruser_id: 0
             deleted: 0
             disable: 0
           starttime: 0
             endtime: 0
         description: NULL
            username: <username>
              avatar: 0
            password: <some hash>
               admin: 0
           usergroup: 2
                lang: default
               email: <email@adress>
      db_mountpoints: NULL
             options: 3
            realName: <real name of user>
            userMods: NULL
   allowed_languages:
                  uc: NULL
    file_mountpoints: NULL
    file_permissions: readFolder,writeFolder,addFolder,renameFolder,moveFolder,deleteFolder,readFile,writeFile,addFile,renameFile,replaceFile,moveFile,copyFile,deleteFile
     workspace_perms: 1
            TSconfig: NULL
           lastlogin: 0
        workspace_id: 0
                 mfa: NULL
      category_perms: NULL
password_reset_token:
 tx_igldapssoauth_dn:
 tx_igldapssoauth_id: 2

[afle]

[xperseguers]

tx_igldapssoauth_dn is empty, that's not possible if related to LDAP, there's a problem somewhere as you must read the corresponding DN.

[xperseguers]

@afle Empty tx_igldapssoauth_dn, is it possible that somehow you do not have any dn attribute with your LDAP server? Because that field is mapped statically, see https://github.com/xperseguers/t3ext-ig_ldap_sso_auth/blob/master/Classes/Library/Configuration.php#L216

[afle]

tx_igldapssoauth_dn is empty, that's not possible if related to LDAP, there's a problem somewhere as you must read the corresponding DN.

Yes, seems so. But when looking to Import LDAP users (Backend) all users with the correct DN are shown.

I also tried to set _tx_igldapssoauthdn in be_users, than click on "update" at Import LDAP users (Backend) and the database field will be cleared. No error message in TYPO oder webserver log. PHP version 8.1.6.

[afle]

@afle Empty tx_igldapssoauth_dn, is it possible that somehow you do not have any dn attribute with your LDAP server?

Each LDAP object has an attribute dn.

Maybe _ldap_getdn would be an idea: https://www.php.net/manual/de/function.ldap-get-dn.php

What me surpise: why I get the DN in the list of Import LDAP users (Backend) ? There the DN can be read correctly.

[xperseguers]

Is it possible for you to debug and figure out where it gets "erased" or why it fails to be persisted to database? As said, in my tests that field is properly persisted in DB.

[afle]

In principle debugging is possible, yes. But how?

[afle]

Enabled logging of database server: seems, that the application does not even try to update the field "tx_igldapssoauth_dn" when click on the "update" button in the backend:

Execute UPDATEbe_usersSETuid= '4',pid= '0',tstamp= '1654782906',crdate= '1653910389',cruser_id= '0',deleted= '0',disable= '0',starttime= '0',endtime= '0',description= NULL,username= '<the username>', avatar = '0', password = '', admin = '0', usergroup = '2', lang = 'default', email = '', db_mountpoints = NULL, options = '3', realName = '', userMods = NULL, allowed_languages = '', uc = NULL, file_mountpoints = NULL, file_permissions = 'readFolder,writeFolder,addFolder,renameFolder,moveFolder,deleteFolder,readFile,writeFile,addFile,renameFile,replaceFile,moveFile,copyFile,deleteFile', workspace_perms = '1', TSconfig = NULL, lastlogin = '0', workspace_id = '0', mfa = NULL, category_perms = NULL, password_reset_token = '', tx_igldapssoauth_dn = '', tx_igldapssoauth_id = '3' WHERE uid = '4'`

When importing users, following entry apears in the TYPO log:

Core: Error handler (BE): PHP Warning: Undefined array key "uid" in /srv/intranet/ssl/typo3conf/ext/ig_ldap_sso_auth/Classes/Controller/ModuleController.php line 485

[xperseguers]

Enabled logging of database server: seems, that the application does not even try to update the field "tx_igldapssoauth_dn" when click on the "update" button in the backend:

It does update the field, since you have double single quotes and you see the field in the update list. So the problem is really that somehow the field is "unread" at some point.

But this is not related to the "status of TYPO3 v11" anymore. So please debug further and report to a dedicated ticket related to that issue specifically.

BTW I just release a "preview release" of this extension on Packagist and TER, so I'll close that ticket. Thanks for your understanding.