I Initially thought this was a client problem that i have reported here but further investigation led to the possibility of this beeing unexpected behaviour on the server side.
(all mentioned tokens have been deleted before publishing this issue)
It seems, that the culprit in my case is a combination of how the App token is generated and how the login process initiates the user context. In detail:
the native nextcloud login accepts any case variation of the username and maps it to an existing user, but retains the username used to login in a case sensitive state
when generating a app token, it will create "new" credentials based on the username used to log in and the generated password
as far as I can see, during the login process with an app token, the login session itself identifies as the username as it is recorded in the nextcloud user db, not the app token name
These "invalid" app tokens can't be used in my case in the native flow but is still usable for WebDAV authentication.
I am not sure if this is intended, a conflict in how different login flows are handled or something else entirely.
Steps to reproduce
Create a user (any name)
log in to this user via web with the same username but different capatilization of characters
create a app token (observe: app token username is case-identical to the one used in the login, not the stored username in NC)
try to login using the provided app token credentials
Expected behavior
Login should be possible using the native app loging flow but it gets rejected.
Although this login CAN be used in other authentication flows (I tested WebDAV).
Installation method
Official All-in-One appliance
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
(posted on my NC, bc GitHub complaned: "There was an error creating your issue: body is too long, body is too long (maximum is 65536 characters). Comment is too long")
Link: EXPIRED
Password: EXPIRED
EDIT 08.07.2024:
The link and share have expired. If you need them for triage, hit me up!
⚠️ This issue respects the following points: ⚠️
Bug description
I just tried to connect to my NC instance using an app token and the native login flow. Checking Nextcloud logs i noticed following entry:
I Initially thought this was a client problem that i have reported here but further investigation led to the possibility of this beeing unexpected behaviour on the server side.
(all mentioned tokens have been deleted before publishing this issue)
It seems, that the culprit in my case is a combination of how the App token is generated and how the login process initiates the user context. In detail:
These "invalid" app tokens can't be used in my case in the native flow but is still usable for WebDAV authentication.
I am not sure if this is intended, a conflict in how different login flows are handled or something else entirely.
Steps to reproduce
Expected behavior
Login should be possible using the native app loging flow but it gets rejected. Although this login CAN be used in other authentication flows (I tested WebDAV).
Installation method
Official All-in-One appliance
Nextcloud Server version
28
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
Fresh Nextcloud Server install
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
EDIT 08.07.2024: The link and share have expired. If you need them for triage, hit me up!
Additional info
No response