Skip to content

Provisioned accounts never auto-refresh the INBOX for passwordless (OIDC/SAML) sessions, even with a master password configured #13807

Description

@mrtxmrtx

Steps to reproduce

  1. Configure account provisioning with "Use master password" (and a master user, 5.12.0+), so provisioned accounts work without the user's login password
  2. Log in to Nextcloud with a passwordless backend, e.g. user_oidc (the session's login password is empty)
  3. Open Mail, stay on the account's INBOX (or the unified/priority inbox) without touching the page
  4. Send a message to the account from outside

Expected behavior

The new message appears in the open INBOX within the regular polling interval, as it does for a user who logged in with a password.

Actual behavior

The message does not appear, even after ten minutes and with app.mail.background-sync-interval
set to 300. It appears immediately when switching to another folder and back, or on a page reload. The unread counter may update earlier than the list.

Cause, as far as we can read it (v5.12.3)

  • PageController::index() sets the initial state password-is-unavailable to true when the login credentials hold no password, which is always the case for user_oidc sessions
  • src/store/mainStore/actions.js (syncInboxes(), and the unified and priority inbox branches of syncEnvelopes()) then excludes every account with a provisioningId ("Skip superfluous requests if using passwordless authentication. They will fail anyway."). This dates from #7616 (2022), before the master password existed (#9008, 2023)
  • Mailbox.vue's 60-second loadMailbox() skips the INBOX by design, since syncInboxes() is meant to cover it (see #13205, withdrawn after review)
  • So with a master password, where these requests would not fail, the INBOX of a provisioned account is never refreshed in the browser. Navigation.vue checks mainStore.masterPasswordEnabled for a related case, but nothing sets that value, so the frontend has no way to tell
  • The backend part was fixed in #9653 (provisioning with a master password for accounts without one); the frontend skip was not revisited

Possible fix: pass to the page whether the user's provisioning config uses a master password, and skip only when it does not.

Related:

#12163, #7520, #7616, #9008, #9653, #13205, #13797

(the QA checklist expects such accounts to show as disabled).

Mail app version

5.12.3

Nextcloud version

34.0.3

Mailserver or service

Dovecot 2.3.21 (master user login), Postfix

Operating system

Linux server; Firefox on Linux

PHP engine version

Other

Nextcloud memory caching

No response

Web server

Apache (supported)

Database

PostgreSQL

Additional info

Login through user_oidc 8.11.0. The account is provisioned and works: sending, Sieve and folder views all pass; only the automatic INBOX refresh is missing.

Activity

  1. added theissue type on Oct 5, 2026
  2. kesselb commented on Oct 6, 2026

    @kesselb
    Contributor

    I did not reproduce, but looks like a valid finding. When you manually refresh the page new messages appear?

  3. mrtxmrtx commented on Oct 6, 2026

    @mrtxmrtx
    Author
  4. kesselb commented on Oct 6, 2026

    @kesselb
    Contributor

    Looks correct:

    isDisabled(account) {
    return (this.passwordIsUnavailable && !!account.provisioningId) && !!this.mainStore.masterPasswordEnabled
    },

    Looks wrong:

    // Skip superfluous requests if using passwordless authentication. They will fail anyway.
    const passwordIsUnavailable = this.getPreference('password-is-unavailable', false)
    const isDisabled = (account) => passwordIsUnavailable && !!account.provisioningId

  5. added
    good first issueSmall tasks with clear documentation about how and in which place you need to fix things in.
    on Oct 6, 2026
  6. kesselb commented on Oct 6, 2026

    @kesselb
    Contributor

    good first issue

    I'm unsure if it's really a good first issue. It seems weird to have masterPasswordEnabled in our main store, while that flag actually belongs to the provisioning for a given account. For one account it can be true, while for another it's false.

    However the setter setMasterPasswordEnabledMutation is nowhere called. Probably the code in navigation only looks correct, but also does not work as expected.

  7. mrtxmrtx commented on Oct 7, 2026

    @mrtxmrtx
    Author

    Looks like #13812 could work for our specific setup, a per account setting as recommended by kesselb would be cleaner.
    The underlying security problem remains the same, that there has to be either one master password for all accounts in nextcloud mail or a password for each mail account.
    A cleaner solution could be a XOAUTH2 Token login for provisioned accounts for IMAP and SMTP, that changes before every (background) connection. Similar to #13311 or #13317

    That would also require a Token login for Sieve to apply filters and out-of-office rules, which is mentioned nowhere.

    Ideally Mail would get it's own refresh token instead of recycling nextcloud's session token, which is messy and against authentik's guidelines. Authentik introduced token exchange recently that allows swapping tokens cleanly on demand.

    But this looks like more effort than just applying something like #13812

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    1. to developbuggood first issueSmall tasks with clear documentation about how and in which place you need to fix things in.

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions