[Bug]: add-app-password generated token are bad (and shouldn't ask for a password)

[quenenni]

⚠️ 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 adapted a Roundcube plugin (https://github.com/mstilkerich/rcmcarddav) to be able to auto synchronize users cloud addressbooks into their roundcube.

With the Nextcloud plugin https://github.com/pulsejet/nextcloud-oidc-login we were initially using, we could connect to Nextcloud from Roundcube thanks to the bearer token, but we had to switch to the other Nextcloud OIDC plugin https://github.com/nextcloud/user_oidc, and with that one, using the bearer token isn't working anymore (nextcloud/user_oidc#603).

So I decided to modify the carddav plugin to be able to use an app password to make the connection.

If I use a token I generated myself from my cloud account, everything is working perfectly, synchronisations, modifications, .. are good. new addressbooks are auto added into Roundcube.

If I use a token generated bu the CLI command add-app-password, giving a fake or the right user password, it doesn't work.

Why are you asking the user password to generate an app password via the CLI, that makes no sense to me (#26563 already explained that problem).

Second, why a token generated via the CLI doesn't work to synchronize address books?

Steps to reproduce

1. Complicated to reproduce as you have to modify the Roundcube carddav plugin in order to be able to test it.

Expected behavior

Generating an app password from the Cli should have the same rights as generating an app password from the Web Ui.

Installation method

Other Community project

Nextcloud Server version

24

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Nginx

Database engine version

MariaDB

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

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

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

Configuration report

{
    "system": {
        "trusted_domains": [
            "cloud.xxxxx.be",
            "cloud.yyyyyy.be"
        ],  
        "activity_expire_days": 30,
        "appstoreenabled": true,
        "appstore.experimental.enabled": false,
        "auth.bruteforce.protection.enabled": true,
        "default_phone_region": "be",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "data-fingerprint": "",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "",
        "dbtype": "mysql",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "default_language": "fr",
        "hashingCost": 10,
        "htaccess.RewriteBase": "\/",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "integrity.check.disabled": true,
        "localstorage.allowsymlinks": true,  
        "logfile": "\/var\/log\/nextcloud\xxxxx.log",
        "loglevel": 3,
        "logtimezone": "Europe\/Brussels",   
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_smtpport": 25,
        "maintenance": false,
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0,
            "dbindex": 1,
            "timeout": 1.5
        },
        "minimum.supported.desktop.version": "2.1.0",
        "mysql.utf8mb4": true,
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "preview_libreoffice_path": "\/usr\/bin\/libreoffice",
        "preview_max_filesize_image": 10,
        "secret": "***REMOVED SENSITIVE VALUE***",
        "simpleSignUpLink.shown": false,
        "trashbin_retention_obligation": "auto, 30",
        "updatechecker": true,
        "upgrade.disable-web": true,
        "version": "24.0.3.2",
        "versions_retention_obligation": "auto, 90",
        "overwrite.cli.url": "https:\/\/cloud.actic.be\/",
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory"
    }
}

List of activated Apps

Enabled:
  - activity: 2.16.0
  - appointments: 1.14.11
  - apporder: 0.15.0
  - bbb: 2.4.0
  - bookmarks: 11.0.4
  - calendar: 3.5.5
  - cloud_federation_api: 1.7.0
  - comments: 1.14.0
  - contacts: 4.2.5
  - dav: 1.22.0
  - federatedfilesharing: 1.14.0
  - files: 1.19.0
  - files_automatedtagging: 1.14.1
  - files_downloadactivity: 1.15.0
  - files_markdown: 2.3.6
  - files_mindmap: 0.0.27
  - files_pdfviewer: 2.5.0
  - files_sharing: 1.16.2
  - files_trashbin: 1.14.0
  - files_versions: 1.17.0
  - files_videoplayer: 1.13.0
  - forms: 2.5.2
  - impersonate: 1.11.1
  - lookup_server_connector: 1.12.0
  - notifications: 2.12.0
  - oauth2: 1.12.0
  - onlyoffice: 7.5.8
  - ownpad: 0.7.1
  - password_policy: 1.14.0
  - photos: 1.6.0
  - privacy: 1.8.0
  - provisioning_api: 1.14.0
  - ransomware_protection: 1.14.0
  - richdocuments: 6.3.4
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - sharebymail: 1.14.0
  - socialsharing_email: 2.5.0
  - spreed: 14.0.9
  - systemtags: 1.14.0
  - tasks: 0.14.5
  - text: 3.5.1
  - theming: 1.15.0
  - timetracker: 0.0.77
  - twofactor_backupcodes: 1.13.0
  - user_ldap: 1.14.1
  - user_status: 1.4.0
  - viewer: 1.8.0
  - workflowengine: 2.6.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

When using an app token generated by the CLI, I have this error:

"No public access to this resource., No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigure"

Additional info

Installation method -> Debian package.

[quenenni]

I noticed that the "bad" app password token is working if used it in Thunderbird to add an addressbook.
I also noticed that the "bad" app password is working from roundcube when adding manually an addressbook.

So maybe, the problem can come from the discovery part of the plugin.
Still, I don't understand why i works with an app password generated from the WebUi, but not with an app password generated from the CLI.

I created an issue in the plugin repo (mstilkerich/rcmcarddav#432).

Hopefully, someone will see the problem.

And for the password asked when generated an app password from the Cli, I really don't understand why it's required, but at least I know I can create one without Nextcloud asking for a password with the "--password-from-env" parameter.

[quenenni]

I was able to finally understand what was the problem.
It was a mix of 3 problems.
One of them was the 5 min lifetime for a ClI generated app password token

The two others are understood and fixed, but because of the 5 min lifetime problem, my system only works for 5 min then not more synchronisation possible (the same if I use a Cli generated token in Thunderbird )

I thought I did tests on a Nc24.0.3 (but without user_oidc app) and the token stayed good indefinitively, but now I updated my test NC to v25 (the one with user_oidc app), the token is again valid only 5 min.

I really need them to stay good indefinitively.

I tried, in the file core/Command/User/AddAppPassword.php to play with the constant DO_NOT_REMEMBER changed to REMEBER when creating the token, but that didn't change anything.

        $generatedToken = $this->tokenProvider->generateToken(
            $token,
            $user->getUID(),
            $user->getUID(),
            $password,
            'cli',
            IToken::PERMANENT_TOKEN,
            IToken::REMEMBER
        );

Can you tell me how to remove that 5 min validity for CLI generated token?

Thank you.

[quenenni]

I would like also to advocate for a better cli command app-password-token.

In a SSO setup, when a part of the equation doesn't recognise (yet) an authentication via the bearer token, we can resort to use an app password token, waiting for the feature to be coded.
In example, synchronising addressbooks / agendas in Thunderbird (Iirc, it's planned in the future for TB) or in Roundcube (here, it's the user_oidc app that doesn't accept bearer token via webdav.. yet).

The app password token is very important to have temporary solutions, and the one generated from the CLI should have the same right as the one generated from the Web Ui.

Also, lots fo good features can be added to that CLI command.
This older request explains it well:
#29001

Thanks

[quenenni]

I noticed a log line I didn't see before in nextcloud log.
It's when the 5 min are over.
In the next requests, I found this:

{"reqId":"U3GJMkHkYgkYHeP5VPYo","level":3,"time":"April 14, 2023 14:57:28","remoteAddr":"111.222.333.444","user":"--","app":"no app in context","method":"PROPFIND","url":"/remote.php/dav","message":"App token login name does not match","userAgent":"GuzzleHttp/6.5.5 curl/7.74.0 PHP/8.0.13","version":"25.0.5.1","data":{"tokenLoginName":"quenenni","sessionLoginName":"[quenenni@YYYY.coop](mailto:quenenni@YYYY.coop)"}}

From my understanding, there is a mix between the login used in the new authentication process (the login version) and the one already redistered in session (the mail version).
But I have no clue where, why or how it is done.
It's not on the Roundcube carddav plugin side as I checked the Authorization header and they are good (and the same on all the requests).

I tested by disabling the user_oidc plugin and the token stayed good after the 5 mins.
But, I don't know if the problem is in the Nextcloud server code or in the user_oidc plugin.

Debug that seemed too much for me, so I decided to come back to use the login and not the mail for the authentication process between roundcube and Nextcloud.
It was working except I didn't have the case sensitive version of the login and for users with uppercases, it was not working.

I found a way to get my case sensitive login from the access token and use it in the carddav plugin context (mstilkerich/rcmcarddav#433).

It's now working with logins that contains uppercase letters and the token doesn't have anymore the 5 min lifetime.