Repository navigation
[Bug]: App token login name does not match error (on Calendar access through MacOS CalendarAgent) #37779
Description
Activity
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 tohttps://server/remote.php/dav/calendars/user/calendarinstead.(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.)
Reacted by Saijin-NaibWe have the same error but also for webDAV clients. Creating new app password solves the issue as workaround on our site.
Reacted by mwinkens and Fabian greger- changed the title
[-][Bug]: App token login name does not match (Calendar access through MacOS CalendarAgent)[/-][+][Bug]: `App token login name does not match` error (on Calendar access through MacOS CalendarAgent)[/+]on Sep 24, 2023 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/
Reacted by Saijin-Naib{"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 thesessionLoginName(specified by the user for this transaction's authentication request):server/lib/private/User/Session.php
Lines 784 to 785 in f8dde2d
i.e. The token (app password) was generated while logged in as
user(tokenLoginName), but the current session is trying to log in asuser_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
- anywhere we tell someone to enter their "Username" / login [User Guide]
- marked [Bug]: App token login name does not match and escaped username on iOS #51928 as a duplicate of this issue
on Apr 4, 2025 Useful log information from #51928
{"reqId":"qVurszARuPnHv0W0EUP5","level":2,"time":"2025-04-04T06:06:42+00:00","remoteAddr":"2001:db8::edb2:6c7e:43f8:6b80","user":false,"app":"core","method":"OPTIONS","url":"/remote.php/dav/principals/users/user%40example.com/","message":"Login failed: 'user%40example.com' (Remote IP: '2001:db8::edb2:6c7e:43f8:6b80')","userAgent":"iOS/18.4 (22E240) remindd/1225.1","version":"31.0.2.1","data":{"app":"core"},"id":"67ef7cd6a2d11"} {"reqId":"qVurszARuPnHv0W0EUP5","level":3,"time":"2025-04-04T06:06:42+00:00","remoteAddr":"2001:db8::edb2:6c7e:43f8:6b80","user":false,"app":"core","method":"OPTIONS","url":"/remote.php/dav/principals/users/user%40example.com/","message":"App token login name does not match","userAgent":"iOS/18.4 (22E240) remindd/1225.1","version":"31.0.2.1","data":{"tokenLoginName":"user@example.com","sessionLoginName":"user%40example.com","app":"core","user":"user@example.com"},"id":"67ef7cd6a2d20"}As you can see here:
- tokenLoginName:
user@example.com - sessionLoginName:
user%40example.com - user:
user@example.com
The problem is that the session login name is URL encoded, this might be a bug of the iOS client or Nextcloud and needs investigation.
- tokenLoginName:
@nicokaiser from your log I can see you use iOS 18.4. This has a known regression with special characters in the usernames:
https://www.reddit.com/r/ios/comments/1joawhy/ios_184_update_bug_with_google_calendar_sync/?sort=newTry the work around:
- Go to iOS settings.
- Select all apps > calendar > accounts > select effected account > account settings.
- Disable calendar toggle (just disable by toggle, not remove account completely).
- Replaced @ with @ in username (so just delete current @ and add a new one manually).
- Type in or copy in the existing app password again.
- Select "done" (and re-enable calendar toggle afterwards if needed). Now it verifies correctly and the calendar connection via CalDAV is working again.
@ChristophWurst do you think we should try
urldecodeif the login name does not match the token name first before hard fail?We could try that
Wow, replacing the @ with @ (sic!) has helped! Thanks @susnux!
The suggestedurldecodemight solve the problem for many (iOS) users as long as iOS behaves like this. Since also Google is affected Apple might patch it eventually...Another solution which has worked for me: In the Nextcloud web application, go to your settings > Mobile & Desktop. There, you can download a macOS/iOS configuration profile. This profile can then be opened on the iPhone to import the config correctly.
Wow, THANK YOU! Just randomly bumped into this on ALL of my iOS devices this morning. Everything worked fine for over a year and then this morning, nothing worked. Turns out everyone was logged in with their Email address and switching to use their User ID instead fixed it.
Two things after digging through this thread, because it has two different problems in it.
1. The percent-encoding one. @susnux suggested decoding on a mismatch and @ChristophWurst said it was worth trying, but nothing was ever written, so I opened #64324. It keeps the exact comparison as the only check on the happy path and decodes once before giving up (
rawurldecode, so a literal+in a login name is not turned into a space). Unit tests included. That should cover the iOS 18.4 reports here and in #51928.2. The e-mail versus user id one - which is what @chrisl8 hit above ("everyone was logged in with their Email address and switching to use their User ID instead fixed it"), and what the
TODOinvalidateTokenLoginName()describes.That one is not an oversight: it is documented as intended behaviour. #42971 added the login-name check to the e-mail fallback in
logClientIn()and its test matrix listsLog in with email and app password generated with username login -> fails gracefully as expected
So an app password created while logged in as
userwill never be usable withuser@example.com, and vice versa, and which of the two you get depends only on what you happened to type in the browser when you pressed "Create app password". That is very hard to guess from the client side, where the only symptom is a generic credentials error.Is there appetite for making that case work? It is a behavioural change in the auth path rather than a bug fix, so I did not want to write code for it before asking. Happy to have a go if you have a preferred shape, or to leave it alone if the current behaviour is deliberate.
Reacted by Christen Lofland
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:
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
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?
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
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response