nextcloud / nextcloud/mail

Mail accounts created via provisioning do not work; "Invalid microsoft_oauth_client_id data provided to provideInitialState by mail" and "Invalid google_oauth_client_id data provided to provideInitialState by mail"

Open
#9,230 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

1. to develop bug stale
Dominant language
JavaScript
Stars
1k
Forks
348
Avg merge
12h 28m
Merged PRs (30d)
91

Description

Steps to reproduce

I am running Nextcloud 28.0.1 with Mail App 3.5.0 and try to provision mail accounts via ./settings/admin/groupware. On the same server I run Dovecot 2.3.20 with a "master" password to fake SSO.

  1. Go to ./settings/admin/groupware, fill out Mail App Provisioning Settings for IMAP and SMTP, but neither configure GMail nor Microsoft integration
  2. Save config and click "Provision all accounts" (verify that the number of created accounts is as expected)
  3. Open Mail App and try to do something, e.g. send a new mail
  4. See a success message, shortly followed by an error message

In the Nextcloud logs I see the following errors (always in pairs):

Level      Application          Message
--------------------------------------------------------------------------------------------------------------
Warning    no app in context    Invalid microsoft_oauth_client_id data provided to provideInitialState by mail
Warning    no app in context    Invalid google_oauth_client_id data provided to provideInitialState by mail 

In order to ensure that there in nothing wrong on the server-side (e.g. Dovecot), I enabled authentication debugging in Dovecot, i.e. I set auth_verbose = yes, auth_verbose_passwords = yes, auth_debug = yes and auth_debug_passwords = yes in Dovecot. I get the following logs in Dovecot

auth: Debug: client in: AUTH   1   PLAIN   service=imap   secured=tls   session=Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB   lip=2a03:4000:5a:d9b::1   rip=2a03:4000:5a:d9b::1   lport=993   rport=32866   local_name=server.mhnnet.de   resp=<auth data> (previous base64 data may contain sensitive data)
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): Performing passdb lookup
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): lookup
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): allow_nets: Matching for network local
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): allow_nets: Matching for network 127.0.0.1/32
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): allow_nets: Matching for network ::1/128
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): allow_nets: Matching for network 202.61.202.193/32
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): allow_nets: Matching for network 2a03:4000:5a:d9b::1/128
auth: Debug: static(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): Finished passdb lookup
auth: Debug: auth(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): Auth request finished
auth: Debug: client passdb out: OK   1   user=<my-uid>@<my-domain.tld>
auth: Debug: auth client connected (pid=35882)
auth: Debug: master in: REQUEST   1022099457   35865   1   54318cf23b0d10441a76049ff2ffc04d   session_pid=35883   request_auth_token
auth: Debug: ldap(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): Performing userdb lookup
auth: Debug: ldap(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): user search: base=dc=server,dc=mhnnet,dc=de scope=subtree filter=(&(objectClass=mailAccount)(mailAccount=<my-uid>@<my-domain.tld>)) fields=uid,uid
auth: Debug: ldap(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): result: uid=<my-uid>; uid unused
auth: Debug: ldap(<my-uid>@<my-domain.tld>,2a03:4000:5a:d9b::1,<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>): Finished userdb lookup
auth: Debug: master userdb out: USER   1022099457   <my-uid>@<my-domain.tld>   uid=999   gid=999   home=/var/spool/mail/vmail/<my-domain.tld>/<my-uid>   auth_mech=PLAIN   auth_token=b392817930fef857a921831f417f9c4c297a2103
imap-login: Login: user=<<my-uid>@<my-domain.tld>>, method=PLAIN, rip=2a03:4000:5a:d9b::1, lip=2a03:4000:5a:d9b::1, mpid=35883, TLS, session=<Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>
imap(<my-uid>@<my-domain.tld>)<35883><Z6ccAHMOYoAqA0AAAFoNmwAAAAAAAAAB>: Disconnected: Logged out in=296 out=1615 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0

From the perspective of Dovecot, everything looks fine: the authentication succeeds, but the client (i.e. the Nextcloud Mail App) immediately logs out again without actually doing anything. I also confirmed manually via openssl s_client ... that log in with the user name and master password works.

My best guess: It seems that the Mail App closes the connection again as it stumbles upon Microsoft and Gmail integration not being configured.

Expected behavior

Provisioned mail accounts should also work without Microsoft and Gmail integration being set.

Actual behavior

Seemingly, mail accounts which have been centrally provisioned do not work without Microsoft and Gmail integration being set, too.

Mail app version

3.5.0

Mailserver or service

Self-hosted Dovecot on same machine

Operating system

Gentoo Linux

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database

None

Additional info

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start from the Mail App provisioning settings at ./settings/admin/groupware and the provideInitialState warnings for microsoft_oauth_client_id and google_oauth_client_id. Reproduce the issue with both integrations unset and a provisioned Dovecot account, then trace why the connection closes; done means provisioned accounts can send mail without either integration configured.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, php
Domain
authentication, backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.