Omeka - platform for digital cultural heritage web publishing

[jeau]

@nebulon on Cloudron gitlab, my account is also @jeau

[nebulon]

@jeau thanks, can you try again?

[jeau]

@nebulon thank's, it works

[jeau]

@girish, I'm trying to go ahead with the configuration of Ldap module.

Settings are located at the bottom of /app/data/config/local.config.php

The following configuration allows a first authentication from the username however the account created does not retrieve the email address but an address like this <username>@<ip>.

   'ldap' => [
        'adapter_options' => [
            'server1' => [
                'host' => getenv('CLOUDRON_LDAP_SERVER'),
                'port' => getenv('CLOUDRON_LDAP_PORT'),
                'username' => getenv('CLOUDRON_LDAP_BIND_DN'),
                'password' => getenv('CLOUDRON_LDAP_BIND_PASSWORD'),
                'bindRequiresDn' => true,
                'baseDn' => getenv('CLOUDRON_LDAP_USERS_BASE_DN'),
                'accountFilterFormat' => '(&(objectClass=user)(username=%s))',
                'accountCanonicalForm' => 4,
                'accountDomainName' => getenv('CLOUDRON_LDAP_HOST'),
            ],
        ],
    ],

With Omeka, it is usual to connect with the mail but the filter (&(objectClass=user)(mail=%s)) does not work.

The module documentation is here https://github.com/biblibre/omeka-s-module-Ldap

[girish]

@jeau the settings look correct to me. Is there anything in the logs? Otherwise, if you can push your changes, I can quickly test here.

[girish]

OK, just testing out if it's something obvious. But the LDAP server does not get any requests at all from omeka

[girish]

So, after some debugging I found that the LDAP code hits a LDAP_X_DOMAIN_MISMATCH exception. This is because of the accountDomainName looks like. It expects the email ids to be in the same domain as the one we set there. Removing it, still fails though.

[girish]

this works (login with username and not email):

    'ldap' => [
        'adapter_options' => [
            'server1' => [
                'host' => getenv('CLOUDRON_LDAP_SERVER'),
                'port' => getenv('CLOUDRON_LDAP_PORT'),
                'username' => getenv('CLOUDRON_LDAP_BIND_DN'),
                'password' => getenv('CLOUDRON_LDAP_BIND_PASSWORD'),
                'bindRequiresDn' => true,
                'baseDn' => getenv('CLOUDRON_LDAP_USERS_BASE_DN'),
                'accountFilterFormat' => '(&(objectclass=user)(username=%s))',
                'accountCanonicalForm' => 1,
                // 'accountDomainName' => getenv('CLOUDRON_LDAP_HOST'),
            ],
        ],
    ],

[girish]

@jeau it seems the email and displayname fields are simply filled with the DN like cn=uid-fc561e94-2711-4411-83cd-4d9a7ffe57d4,ou=users,dc=cloudron . I guess we need to ask the module-ldap author on how we can get this properly read in from LDAP.

[jeau]

@girish yes, I asked Julian from Biblibre who who develops this module. He talk me that the current released (0.3.0) of Ldap module I used does not allow to configure the LDAP attributes to retrieve the name and email. I tried from source, it's works partially, I retreive the user mail address but I can sign in only with username, not mail.

[imc67]

@jeau said in Omeka - platform for digital cultural heritage web publishing:

I can sign in only with username

That is no problem at all as app like Wordpress and Nextcloud also uses usernames as login.

[jeau]

@imc67 you're right, it's works with the Ldap module, but usually Omeka S users use their email address and in their profile there's no username.

[girish]

@jeau atleast the login form of omeka s says "email or username".

[imc67]

@girish said in Omeka - platform for digital cultural heritage web publishing:

@jeau atleast the login form of omeka s says "email or username".

Indeed and for me it’s ok. And for the time being as “Unstable” in the AppStore it might be possible to use username as Account name?

[jeau]

@girish I never understood why the form asks for name or email. I didn't submit any changes either.

I just found the module UserNames who solve this issue. I can install it by default.

@imc67 I hope it will be possible soon.

[jeau]

Oups, UserNames module broke ldap access I will report this issue.

[jeau]

@girish I installed some components required for official modules and made some settings and tests. I think we can provide this application as "unstable" in the store. I hope I haven't forgotten anything important.

[nebulon]

@jeau this is great! I've just ran the tests and we are looking good.
I will update the manifest to add things like mediaLinks and such for the appstore and then push it out as unstable later today.

Thanks a lot for the work

[jeau]

@nebulon thank's

About tests. Is there a way to test the ldap connection? For my tests, I could connect with my initial administrator, activate and configure the Ldap module but then how to verify? I can't seriously give a Cloudron login and password inside my test code and repo.

[nebulon]

@jeau I've now pushed it as unstable for a start to collect further feedback.

Regarding the LDAP tests, I have to take a closer look as well how to do that. If you are just concerned about the username/password, then we usually follow the pattern that you run the tests with a USERNAME and PASSWORD env variable locally against a test Cloudron. But since we have the package now in the store, we will test new releases from here on on our test Cloudrons anyways.