Omeka - platform for digital cultural heritage web publishing

[seeker]

Very cool to seeing Omeka on the horizon! This platform is used by many who need a turn key solution like Cloudron

[jeau]

@imc67 @scooke you are right, this components need to be pre-installed in the OS. I can add them.

On the Omeka S app, you can install manually themes and plugins (modules) inside the /app/datadirectory. I installed LDAP module and I hesitated to install EasyInstall module whitch allows to install Omeka S modules and themes from https://omeka.org and from the web (https://github.com and https://gitlab.com). But it isn't possible to check all the dependencies required by all these components and I am afraid that the users do not pay attention to this issue.

However, I'm thinking of check the dependencies required by the modules of the official modules list. Extract Text is present in this list.

[jeau]

@seeker I also think that many users will be interested in simply manage this kind of tools useful for heritage and digital humanities. For example Cantaloupe IIIF Image Server or Mirador Viewer that I already added to App Wishlist.

[seeker]

@jeau Agreed
There is also Scalar
https://guides.library.illinois.edu/scalar

[jeau]

@nebulon I added the optional dependencies of Omeka S and the dependencies required by the modules listed on the official website.

However, I have this error when I try to push this commit to our repository:

 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.cloudron.io/cloudron/omeka-s-app.git'

[nebulon]

@jeau ok let me double check this. Which what is the gitlab account you are using?

[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?