[Bug]: log.condition does not work per user!

[akhil1508]

⚠️ This issue respects the following points: ⚠️

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

Bug description

• When using log.condition with 'users' option set to an array of users, there are no debug-level logs for the selected users
• Config looking something like

  •     ...
       'log.condition' => [
            'users' => [
                      ...
             ],
        ],
        ...```
    
    
    
    
    

Steps to reproduce

1. Add log.condition entry to your config.php file with users set to an array of usernames
2. Check if you can see debug logs for given users

Expected behavior

• Debug-level logs should be shown for the selected users

Installation method

Community Docker image

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.0

Web server

Nginx

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 Enabled

What user-backends are you using?

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

Configuration report

No response

List of activated Apps

Enabled:
  - accessibility: 1.10.0
  - activity: 2.16.0
  - admin_audit: 1.14.0
  - announcementcenter: 6.3.1
  - bookmarks: 11.0.4
  - bruteforcesettings: 2.4.0
  - calendar: 3.5.4
  - carnet: 0.24.6
  - cloud_federation_api: 1.7.0
  - comments: 1.14.0
  - contacts: 4.2.3
  - cookbook: 0.9.17
  - dav: 1.22.0
  - deck: 1.7.3
  - drop_account: 2.1.0
  - encryption: 2.12.0
  - external: 4.0.1
  - federatedfilesharing: 1.14.0
  - files: 1.19.0
  - files_pdfviewer: 2.5.0
  - files_rightclick: 1.3.0
  - files_sharing: 1.16.2
  - files_trashbin: 1.14.0
  - files_videoplayer: 1.13.0
  - forms: 2.5.1
  - integration_google: 1.0.8
  - ldap_write_support: 1.6.0
  - logreader: 2.9.0
  - lookup_server_connector: 1.12.0
  - news: 20.0.0
  - notes: 4.5.1
  - notifications: 2.12.1
  - oauth2: 1.12.0
  - onlyoffice: 7.5.8
  - password_policy: 1.14.0
  - passwords: 2022.12.21
  - photos: 1.6.0
  - privacy: 1.8.0
  - provisioning_api: 1.14.0
  - quota_warning: 1.15.0
  - rainloop: 7.2.5
  - recommendations: 1.3.0
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - sharebymail: 1.14.0
  - snappymail: 2.23.1
  - tasks: 0.14.4
  - text: 3.5.1
  - twofactor_admin: 4.1.9
  - twofactor_backupcodes: 1.13.0
  - twofactor_totp: 6.4.0
  - updatenotification: 1.14.0
  - user_ldap: 1.14.1
  - viewer: 1.8.0
  - workflowengine: 2.6.0
Disabled:
  - circles: 0.20.11
  - contactsinteraction: 1.3.0
  - dashboard: 7.3.0
  - federation: 1.9.0
  - files_external: 1.12.1
  - files_versions: 1.14.0
  - firstrunwizard: 2.7.0
  - nextcloud_announcements: 1.10.0
  - support: 1.4.0
  - survey_client: 1.6.0
  - systemtags: 1.9.0
  - theming: 1.12.0
  - user_backend_sql_raw: 1.3.0
  - user_status: 1.2.0
  - weather_status: 1.2.0

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

• I tried logging $user over here using logException and it was null so probably an issue with getting the user from session
• Tested on three different servers with similar config so doesn't seem like an instance-specific issue

[szaimen]

Hi, which nc version?

[akhil1508]

Hi, which nc version?

@szaimen 24.0.8

[szaimen]

this sounds like a feature request

[akhil1508]

this sounds like a feature request

@szaimen Thanks for replying.

It is mentioned in config.sample.php that this is a feature and that log level upgradation for specified users is possible.

There seems to be a bug in Log.php as mentioned in the Additional Details section of the issue.

I am yet to test this in NC25+ though, maybe the bug is fixed there. I update the issue accordingly. But yeah, this is definitely not a feature request IMO.

[szaimen]

I see, you are right then 👍

[szaimen]

Would you mind checking if this is still the case on 25.0.7 or 26.0.2?

[joshtrichards]

Reproduced in v26.0.2. This should work per implementation, but doesn't.

Tough to say whether it's always been broken or just "awhile". I can't find any past reports of a similar nature. 🤷‍♂️

This code has been the same for years, but test coverage is limited to 1 of 3 supported conditionals:

• apps conditional (yes)
• users condition (no)
• shared_secret condition (no)

This call never returns anything:

$user = \OC::$server->getUserSession()->getUser();

(should be an IUserSession)

So $user->getUID() never becomes useable afterward.

I tried just calling \OC_User::getUser() directly for the uid comparison (along with some other variations just for fun), but it's never populated.

Should we be trying to get the uid some other way in that area of code? Is there something special about user session data availability in the logging area?

[szaimen]

Cc @nextcloud/server-backend

[come-nc]

@joshtrichards Could you test https://github.com/nextcloud/server/pull/38881 and check it fixes the problem?