[Bug]: `App token login name does not match` error (on Calendar access through MacOS CalendarAgent)

[b-pfl]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

I am not sure if this issue relates to the core server or the Calendar app. However, looking at the log file and the "missing app in context", it feels to belong to the core server:

{"reqId":"<randomstring>,"level":3,"time":"2023-04-17T23:25:14+00:00","remoteAddr":"<ip>","user":"--","app":"no app in context","method":"REPORT","url":"/remote.php/dav/principals/users/<user>/","message":"App token login name does not match","userAgent":"macOS/12.6.4 (<removed>) CalendarAgent/961.4.2","version":"26.0.0.11","data":{"tokenLoginName":"<user>","sessionLoginName":"<user_address_mail"},"id":"<id>"}

At least since the latest updates (Calendar 4.3.3 and Nextcloud 26.0.0) I frequently get this error message - for instance if I trigger a manual update from an Apple Calendar client (MacOS 12.6.4).

What else is affected is not clear - there are calendar events visible in that corresponding client.

Steps to reproduce

1. Install Nexcloud, set up user and user calendar
2. On MacOS (12.6.4) go to Calendar > Account, add a new CalDav account using the instructions from https://docs.nextcloud.com/server/latest/user_manual/en/groupware/sync_osx.html.
3. Wait for the next synchronization in the Calendar app or trigger it manually using Cmd+R
4. Watch how the error message above shows up on synchronization

Expected behavior

Flawless synchronization without error messages

Installation method

None

Nextcloud Server version

26

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.0

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 22.2.3 to 23.0.1)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "26.0.0.11",
        "installed": true,
        "loglevel": 2,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "theme": "",
        "maintenance": false,
        "trusted_domains": [
            "<domain>"
        ],
        "forcessl": true,
        "mail_smtpmode": "smtp",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "forceSSLforSubdomains": true,
        "default_language": "de",
        "check_for_working_htaccess": true,
        "appcodechecker": true,
        "updatechecker": true,
        "has_internet_connection": "true",
        "trashbin_retention_obligation": "auto",
        "check_for_working_webdav": true,
        "check_for_wellknown_setup": true,
        "appstoreenabled": true,
        "upgrade.disable-web": false,
        "updater.server.url": "https:\/\/updates.nextcloud.com\/updater_server\/",
        "memcache.local": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "password": "***REMOVED SENSITIVE VALUE***",
            "timeout": 0
        },
        "overwrite.cli.url": "https:\/\/<cli_url>",
        "htaccess.RewriteBase": "\/",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "updater.release.channel": "stable",
        "mysql.utf8mb4": true,
        "app_install_overwrite": [
            "twofactor_admin",
            "ransomware_protection",
            "issuetemplate"
        ],
        "mail_sendmailmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
        "encryption.legacy_format_support": false,
        "encryption.key_storage_migrated": false,
        "default_phone_region": "DE",
        "preview_max_x": 1024,
        "preview_max_y": 1024,
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

Enabled:
  - activity: 2.18.0
  - bruteforcesettings: 2.6.0
  - calendar: 4.3.3
  - circles: 26.0.0
  - cloud_federation_api: 1.9.0
  - comments: 1.16.0
  - contacts: 5.2.0
  - contactsinteraction: 1.7.0
  - cookbook: 0.10.2
  - cospend: 1.5.8
  - dashboard: 7.6.0
  - dav: 1.25.0
  - deck: 1.9.0
  - external: 5.1.0
  - federatedfilesharing: 1.16.0
  - federation: 1.16.0
  - files: 1.21.1
  - files_antivirus: 5.0.0
  - files_external: 1.18.0
  - files_pdfviewer: 2.7.0
  - files_rightclick: 1.5.0
  - files_sharing: 1.18.0
  - files_trashbin: 1.16.0
  - files_versions: 1.19.1
  - firstrunwizard: 2.15.0
  - groupfolders: 14.0.1
  - logreader: 2.11.0
  - lookup_server_connector: 1.14.0
  - notes: 4.7.2
  - notifications: 2.14.0
  - oauth2: 1.14.0
  - password_policy: 1.16.0
  - photos: 2.2.0
  - privacy: 1.10.0
  - provisioning_api: 1.16.0
  - quota_warning: 1.16.0
  - ransomware_protection: 1.14.0
  - recommendations: 1.5.0
  - related_resources: 1.1.0-alpha1
  - richdocuments: 8.0.1
  - richdocumentscode: 22.5.1301
  - serverinfo: 1.16.0
  - settings: 1.8.0
  - sharebymail: 1.16.0
  - spreed: 16.0.2
  - support: 1.9.0
  - systemtags: 1.16.0
  - tasks: 0.14.5
  - terms_of_service: 2.1.0
  - text: 3.7.2
  - theming: 2.1.1
  - twofactor_admin: 4.1.9
  - twofactor_backupcodes: 1.15.0
  - twofactor_nextcloud_notification: 3.6.0
  - twofactor_totp: 8.0.0-alpha.0
  - updatenotification: 1.16.0
  - user_status: 1.6.0
  - viewer: 1.10.0
  - weather_status: 1.6.0
  - workflowengine: 2.8.0
Disabled:
  - admin_audit: 1.16.0
  - announcementcenter: 6.5.1 (installed 6.5.1)
  - audioplayer: 3.3.1 (installed 3.3.1)
  - camerarawpreviews: 0.8.1 (installed 0.8.1)
  - checksum: 1.2.1 (installed 1.2.1)
  - documentserver_community: 0.1.13 (installed 0.1.13)
  - encryption: 2.14.0 (installed 2.8.1)
  - end_to_end_encryption: 1.12.4 (installed 1.12.4)
  - files_accesscontrol: 1.16.0 (installed 1.16.0)
  - files_markdown: 2.3.6 (installed 2.3.6)
  - forms: 3.2.0 (installed 3.2.0)
  - issuetemplate: 0.7.0 (installed 0.7.0)
  - maps: 1.0.2 (installed 1.0.2)
  - nextcloud_announcements: 1.15.0 (installed 1.9.0)
  - onlyoffice: 7.8.0 (installed 7.8.0)
  - piwik: 0.11.1 (installed 0.11.1)
  - polls: 5.0.0 (installed 5.0.0)
  - shorten: 0.0.15 (installed 0.0.15)
  - socialsharing_email: 2.5.0 (installed 2.5.0)
  - survey_client: 1.14.0 (installed 0.1.5)
  - suspicious_login: 4.4.0
  - unsplash: 2.2.0 (installed 2.2.0)
  - user_ldap: 1.16.0

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[logic]

FWIW: this was happening to me with Thunderbird as well, using Thunderbird's auto-discovery to generate the URLs for individual calendars.

The "fix" was to trim the trailing slash from the auto-discovered URL.

ie: instead of https://server/remote.php/dav/calendars/user/calendar/ I switched to https://server/remote.php/dav/calendars/user/calendar instead.

(This was showing up for me on 27.0.0 with Calendar 4.4.3; I have no idea if it was happening with earlier versions, since I only tried Thunderbird today to test out their new release.)

[apw1388]

We have the same error but also for webDAV clients. Creating new app password solves the issue as workaround on our site.

[OliverRM]

In our organisation one user also faces the issue. Surprisingly, I don’t find any difference between the users configuration / environment and the configuration of other users, for which it works.

In our case, the users tried to add the calendar using the configuration profile for macOS/iOS. The only workaround found was manually adding the calendar via https://SERVER/remote.php/dav/principals/users/USERNAME/

[joshtrichards]

{"reqId":"<randomstring>,"level":3,"time":"2023-04-17T23:25:14+00:00","remoteAddr":"<ip>","user":"--","app":"no app in context","method":"REPORT","url":"/remote.php/dav/principals/users/<user>/","message":"App token login name does not match","userAgent":"macOS/12.6.4 (<removed>) CalendarAgent/961.4.2","version":"26.0.0.11","data":{"tokenLoginName":"<user>","sessionLoginName":"<user_address_mail"},"id":"<id>"}

This means that user (as stored in the previously generated token) tokenLoginName; pulled from the db) does not equal the sessionLoginName (specified by the user for this transaction's authentication request):

server/lib/private/User/Session.php

Lines 784 to 785 in f8dde2d

	// e.g. login by e-mail 'user@example.com' on browser for generating the token will not
	// allow to use the client token with the login name 'user'.

i.e. The token (app password) was generated while logged in as user (tokenLoginName), but the current session is trying to log in as user_address_mail (sessionLoginName).

When using a device token / app password, the session loginname must match the one that was used when generating the token in the browser.

From the looks of it maybe there are some opportunities to refine the documentation:

• anywhere we tell someone to enter their "Username" / login [User Guide]
  • with an app password (since it needs to match username / login they were logged in as when generating the token)
• anywhere we discuss how to using or generating an app token [User Guide, Admin Guide]

Ref: #42971 and various others