IMAP login completely broken after upgrade from 0.5.1 to 0.6.1

[0x47]

Steps to reproduce

1. Install Nextcloud 15.0.5 and user_external 0.5.1
2. Create users (i.e., login with IMAP credentials) that have a UID without domain part in oc_users_external (e.g. 'user@example.com' -> UID 'user')
3. Upgrade user_external to 0.6.1 and update the config.php accordingly
4. Login does not work and instead creates a new user with 'user@exmaple.com' UID

Expected behaviour

The login with 'user@example.com' should connect to the original 'user' UID or the UID of the original user should be updated system-wide to include the domain part.

Actual behaviour

The login succeeds but creates a brand new user with a different UID. Accessing the old user does not work even after reverting to 0.5.1. Now, even with 0.5.1, the new users are created with the domain part in the UID.

Affected Authentication backend

IMAP

Server configuration

User External App version: 0.5.1 and 0.6.1 (0.6.0 does not work either)

Operating system: Debian 9

Web server: Nginx 1.10.3

Database: MariaDB 10.1.37

PHP version: 7.0.33-0+deb9u3

Nextcloud version: 15.0.5

Updated from an older Nextcloud/ownCloud or fresh install: Updated

Where did you install Nextcloud from: Official release

Signing status:

Signing status

``` No errors have been found. ```

List of activated apps:

App list

``` Enabled: - accessibility: 1.1.0 - activity: 2.8.2 - admin_audit: 1.5.0 - bruteforcesettings: 1.3.0 - cloud_federation_api: 0.1.0 - comments: 1.5.0 - dav: 1.8.1 - federatedfilesharing: 1.5.0 - federation: 1.5.0 - files: 1.10.0 - files_pdfviewer: 1.4.0 - files_sharing: 1.7.0 - files_texteditor: 2.7.0 - files_trashbin: 1.5.0 - files_versions: 1.8.0 - files_videoplayer: 1.4.0 - firstrunwizard: 2.4.0 - gallery: 18.2.0 - logreader: 2.0.0 - lookup_server_connector: 1.3.0 - nextcloud_announcements: 1.4.0 - notifications: 2.3.0 - oauth2: 1.3.0 - password_policy: 1.5.0 - provisioning_api: 1.5.0 - richdocuments: 3.2.4 - serverinfo: 1.5.0 - support: 1.0.0 - survey_client: 1.3.0 - systemtags: 1.5.0 - theming: 1.6.0 - twofactor_backupcodes: 1.4.1 - twofactor_totp: 2.1.2 - updatenotification: 1.5.0 - user_external: 0.5.1 - workflowengine: 1.5.0 Disabled: - encryption - files_external - sharebymail - user_ldap ```

Nextcloud configuration:

Config report

``` { "system": { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "dat.example.com" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "overwrite.cli.url": "https:\/\/dat.exmaple.com", "dbtype": "mysql", "version": "15.0.5.3", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "memcache.local": "\\OC\\Memcache\\APCu", "mail_smtpmode": "smtp", "mail_smtpauthtype": "LOGIN", "mail_smtpsecure": "ssl", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "465", "maintenance": false, "theme": "", "loglevel": 2, "user_backends": [ { "class": "OC_User_IMAP", "arguments": [ "{mail.exmaple.com:143\/imap\/readonly\/tls}" ] } ] } } ```

[0x47]

Any help is much appreciated as currently no users can login to their accounts. I see two possible solutions:

1. Somehow tell user_external to use the old 'user'-UIDs (without '@example.com')
2. Change all UIDs to the new ones (including '@example.com') in the database

Unfortunately I don't know how to do either.

[violoncelloCH]

Thank you for reporting! Could you provide the new/adapted user_backend configuration which you had in config.php for v0.6.X?

Please note, that as the documentation states, the @domain.part is only striped away, if you provide the domain parameter in the config... so you most probably had it there before and did forget to keep it while adapting to the new v0.6.X config...

[0x47]

Thank you for your quick response. The new configuration that was used is as follows:

0 => 
array (
  'class' => 'OC_User_IMAP',
  'arguments' => 
  array (
    0 => 'mail.example2.com',
    1 => 143,
    2 => 'tls',
    3 => '',
  ),
),

However, the pre-0.6.0 configuration does also not contain the domain part (I am not sure if it was even possible to add a domain pre-0.6.0?). As I also read about the domain part in the documentation, I tried to add it afterwards, without success (the damage has probably already been done):

0 => 
array (
  'class' => 'OC_User_IMAP',
  'arguments' => 
  array (
    0 => 'mail.example2.com',
    1 => 143,
    2 => 'tls',
    3 => 'example.com',
  ),
),

Also note that the mail server is indeed a different domain than the host (I reported that wrong in the first post). I wonder if that could be the/an issue?

EDIT: One further note. I quite don't understand this sentence from the documentation:

however if you want to restrict the domain, you need to specify the port and set sslmode to null

Does that mean restricting the domain is only possible without using secure auth for IMAP? Of course, I did not remove the tls part. Is this safe?

[0x47]

I found the relevant part in the Github file history. After adding the domain part in the old configuration the logins are working again. Now, after upgrading and also adding the domain part to the new configuration everything is working as expected. Thanks a lot for your help!

[violoncelloCH]

However, the pre-0.6.0 configuration does also not contain the domain part (I am not sure if it was even possible to add a domain pre-0.6.0?).

Yes, this was already possible... so are you really sure you didn't specify the email domain? (it's indeed normal that this is an other domain than the imap mail servers domain)

EDIT: One further note. I quite don't understand this sentence from the documentation:

however if you want to restrict the domain, you need to specify the port and set sslmode to null

Does that mean restricting the domain is only possible without using secure auth for IMAP? Of course, I did not remove the tls part. Is this safe?

no, that should not be the case; you should be able to specify all of these parameters it's meant that if you want to use the default parameters (port 143 and no sslmode) but want to specify the domain, you need to set null for port and sslmode, because otherwise the domain would be passed as port, if you simply skip port and sslmode

we should probably formulate this in a better way so it's more understandable (thank you for reporting this!) Do you have a concrete suggestion?

[0x47]

Do you have a concrete suggestion?

How about:

The default port is 143. However, note that parameter order matters and if you want to restrict the domain (4th parameter), you need to also specify the port (2nd parameter) and sslmode (3rd parameter; set to null for insecure connection).

Thanks again

[violoncelloCH]

That sounds nice and understandable! Would you like to create a Pull Request for it?

[0x47]

Sure, there you go: #67

[violoncelloCH]

thank you very much :)