Don't open PHP session for status.php

[jplitza]

Steps to reproduce

1. Fetch the status of the instance via status.php, for example via curl -I https://example.com/nextcloud/status.php or your favourite monitoring solution.

Expected behaviour

No new session is created, because a) this most likely is an automated request, and b) status.php doesn't use anything from that session anyway.

Actual behaviour

A new session is created and sent via the Set-Cookie: header, causing stale sessions to pile up due to monitoring requests.

Server configuration detail

Operating system: Debian Stretch

Webserver: Apache

Database: MariaDB

PHP version:

7.0.30

Nextcloud version: 13.0.6 - 13.0.6.1

Updated from an older Nextcloud/ownCloud or fresh install:

Where did you install Nextcloud from:

Signing status

Array ( )

List of activated apps

Enabled:
 - activity: 2.6.1
 - bruteforcesettings: 1.1.0
 - calendar: 1.6.1
 - contacts: 2.1.5
 - dav: 1.4.7
 - federatedfilesharing: 1.3.1
 - federation: 1.3.0
 - files: 1.8.0
 - files_external: 1.4.1
 - files_pdfviewer: 1.2.1
 - files_rightclick: 0.8.4
 - files_sharing: 1.5.0
 - files_snapshots: 0.1.1
 - files_texteditor: 2.5.1
 - files_trashbin: 1.3.0
 - files_versions: 1.6.0
 - files_videoplayer: 1.2.0
 - gallery: 18.0.0
 - impersonate: 1.0.4
 - issuetemplate: 0.4.0
 - logreader: 2.0.0
 - lookup_server_connector: 1.1.0
 - mail: 0.8.3
 - metadata: 0.7.0
 - news: 12.0.4
 - notifications: 2.1.2
 - oauth2: 1.1.1
 - polls: 0.8.3
 - provisioning_api: 1.3.0
 - sharebymail: 1.3.0
 - tasks: 0.9.7
 - theming: 1.4.5
 - twofactor_backupcodes: 1.2.3
 - twofactor_totp: 1.4.1
 - updatenotification: 1.3.0
 - workflowengine: 1.3.0
Disabled:
 - admin_audit
 - comments
 - encryption
 - firstrunwizard
 - nextcloud_announcements
 - password_policy
 - serverinfo
 - survey_client
 - systemtags
 - user_external
 - user_ldap

Configuration (config/config.php)

{
    "instanceid": "***REMOVED SENSITIVE VALUE***",
    "passwordsalt": "***REMOVED SENSITIVE VALUE***",
    "secret": "***REMOVED SENSITIVE VALUE***",
    "trusted_domains": [
        "***REMOVED SENSITIVE VALUE***"
    ],
    "datadirectory": "***REMOVED SENSITIVE VALUE***",
    "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
    "dbtype": "mysql",
    "version": "13.0.6.1",
    "dbname": "***REMOVED SENSITIVE VALUE***",
    "dbhost": "***REMOVED SENSITIVE VALUE***",
    "dbtableprefix": "oc_",
    "dbuser": "***REMOVED SENSITIVE VALUE***",
    "dbpassword": "***REMOVED SENSITIVE VALUE***",
    "logtimezone": "Europe\/Berlin",
    "installed": true,
    "mail_smtpmode": "smtp",
    "mail_from_address": "***REMOVED SENSITIVE VALUE***",
    "mail_domain": "***REMOVED SENSITIVE VALUE***",
    "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
    "maintenance": false,
    "loglevel": 1,
    "log_type": "syslog",
    "updatechecker": true,
    "htaccess.RewriteBase": "\/",
    "appstore.experimental.enabled": true,
    "config_is_read_only": false,
    "check_for_working_htaccess": false,
    "appstoreenabled": true,
    "syslog_tag": "nextcloud",
    "mysql.utf8mb4": true,
    "theme": ""
}

Are you using external storage, if yes which one: local

Are you using encryption:

Are you using an external user-backend, if yes which one:

[nextcloud-bot]

GitMate.io thinks possibly related issues are https://github.com/nextcloud/server/issues/6784 (Php error?), https://github.com/nextcloud/server/issues/850 (Include "nextcloud" in status.php ), https://github.com/nextcloud/server/issues/10751 (It opens /cron.php without login. Is security problem?), https://github.com/nextcloud/server/issues/1632 (Remote.PHP/CalDAV does not send HTTP Status Header), and https://github.com/nextcloud/server/issues/2871 (Webdav usage results in massive number of php sessions).

[ChristophWurst]

This happens because the Nextcloud base system is used, which always starts the session. This is quite hard to fix without any fundamental restructuring.

[kesselb]

This happens because the Nextcloud base system is used, which always starts the session. This is quite hard to fix without any fundamental restructuring.

@ChristophWurst Won't fix for now?

[ChristophWurst]

yep. this is tech dept

[szaimen]

I suppose this issue is still valid? If not, please close this issue!

[ChristophWurst]

It's valid but we can't easily fix this.

[szaimen]

Hi, please update to 24.0.8 or better 25.0.2 and report back if it fixes the issue. Thank you!

[ChristophWurst]

Really?

[szaimen]

Really?

sorry, dont understand...

[ChristophWurst]

https://github.com/nextcloud/server/blob/master/status.php#L37 is still there

[szaimen]

okay, thanks!

[pschichtel]

I can still confirm this on 29.0.1: https://github.com/nextcloud/server/blob/648d9d747bdb00cfc1e47b8de99a2f759aae15e9/status.php#L13

I noticed this because of the healthchecks in nextcloud/helm in combination with session_save_handler = redis, which flooded the redis with session keys.

[joshtrichards]

#28311 might help/be adapted here, but it's currently reverted.