Wrong parameter value for workflow script

[it25fg]

Since upgrade of Nextcloud from 19.0.6 to 19.0.8, a previously working workflow script gets the wrong file name with the %n parameter. It gets the name of the temporary upload file (a path in /tmp) which obviously isn't available anymore when the script is run (in cron.php). If I understand https://github.com/nextcloud/workflow_script#placeholders correctly, the temp name is supposed to appear in the %f variable, not %n. The script worked for a long time, back in the day the plugin was named 'workflow external script'.

Steps to reproduce

1. set up an external script that gets the %n parameter
2. upload a file that satifies the condition of 1
3. verify that %n is the store-relative path of the uploaded file
4. update Nextcloud to 19.0.8
5. upload a second file
6. you'll see that %n now contains the temp file name.

Expected behaviour

The script should get the store-relative filename in %n, as documented.

Actual behaviour

The script gets the name of the temporary file in %n

Workflow Script app

• workflow_script: 1.4.1
• workflowengine: 2.1.0

Server configuration

Nextcloud 19.0.8

Operating system: Debian

Web server: Nginx 1.14.2

Database: MySQL 10.3.27

PHP version: php-fpm 7.4.14

Nextcloud Version: 19.0.8.1

Where did you install Nextcloud from: unknown

Signing status: empty

List of activated apps:

Enabled:

• accessibility: 1.5.0
• activity: 2.12.1
• admin_audit: 1.9.0
• bruteforcesettings: 2.0.1
• calendar: 2.0.4
• checksum: 0.4.5
• cloud_federation_api: 1.2.0
• comments: 1.9.0
• contactsinteraction: 1.0.0
• dav: 1.15.0
• deck: 1.2.4
• federatedfilesharing: 1.9.0
• federation: 1.9.0
• files: 1.14.0
• files_external: 1.10.0
• files_pdfviewer: 1.8.0
• files_rightclick: 0.16.0
• files_sharing: 1.11.0
• files_trashbin: 1.9.0
• files_versions: 1.12.0
• files_videoplayer: 1.8.0
• firstrunwizard: 2.8.0
• logreader: 2.4.0
• lookup_server_connector: 1.7.0
• nextcloud_announcements: 1.8.0
• notes: 3.6.4
• notifications: 2.7.0
• oauth2: 1.7.0
• password_policy: 1.9.1
• photos: 1.1.0
• privacy: 1.3.0
• provisioning_api: 1.9.0
• recommendations: 0.7.0
• serverinfo: 1.9.0
• settings: 1.1.0
• sharebymail: 1.9.0
• sharelisting: 0.3.0
• support: 1.2.1
• survey_client: 1.7.0
• systemtags: 1.9.0
• tasks: 0.13.6
• text: 3.0.1
• theming: 1.10.0
• theming_customcss: 1.6.0
• twofactor_backupcodes: 1.8.0
• updatenotification: 1.9.0
• user_ldap: 1.9.1
• viewer: 1.3.0
• workflow_script: 1.4.1
• workflowengine: 2.1.0
  Disabled:
• encryption

Nextcloud configuration:

{
"instanceid": "REMOVED SENSITIVE VALUE",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"REMOVED SENSITIVE VALUE"
"127.0.0.1"
],
"datadirectory": "REMOVED SENSITIVE VALUE",
"dbtype": "mysql",
"version": "19.0.8.1",
"dbname": "REMOVED SENSITIVE VALUE",
"dbhost": "REMOVED SENSITIVE VALUE",
"dbtableprefix": "oc_",
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"ldapIgnoreNamingRules": false,
"proxy": "REMOVED SENSITIVE VALUE",
"log_type": "syslog",
"logfile": "",
"loglevel": "2",
"log_authfailip": true,
"logtimezone": "Europe/Berlin",
"enable_previews": true,
"forcessl": true,
"singleuser": false,
"maintenance": false,
"appstoreenabled": true,
"has_internet_connection": true,
"supportedDatabases": [
"mysql",
"pgsql",
"oci"
],
"secret": "REMOVED SENSITIVE VALUE",
"share_folder": "/Shared",
"updatechecker": false,
"theme": "",
"memcache.local": "\OC\Memcache\APCu",
"overwrite.cli.url": "REMOVED SENSITIVE VALUE",
"mail_smtpmode": "smtp",
"mail_smtphost": "REMOVED SENSITIVE VALUE",
"mail_smtpport": "25",
"ldapProviderFactory": "\OCA\User_LDAP\LDAPProviderFactory",
"updater.release.channel": "stable",
"default_language": "de_DE",
"mail_from_address": "REMOVED SENSITIVE VALUE",
"mail_smtpauthtype": "LOGIN",
"mail_domain": "REMOVED SENSITIVE VALUE",
"mysql.utf8mb4": true,
"app_install_overwrite": [
"workflow_script",
"calendar",
"spgverein"
]
}
Are you using external storage, if yes which one: CIFS, SFTP

Are you using encryption: no

Server log (data/nextcloud.log)

Nothing.

[dbw9580]

Don't know if it's exactly the same issue, but for me, the culprit was a trailing slash in the path.

Before PR #64, the %n placeholder was handled in Operation.php as:

workflow_script/lib/Operation.php

Line 76 in b00af8b

$command = str_replace('%n', escapeshellarg($node->getPath()), $command);

After PR #64:

workflow_script/lib/Operation.php

Lines 88 to 91 in ba30955

	$base_path = $this->config->getSystemValue('datadirectory');
	$path = Filesystem::getLocalFile(Filesystem::getPath($nodeID));
	$command = str_replace('%n', escapeshellarg(str_replace($base_path . '/', '', $path)), $command);

My paths are:

$base_path	$path
/mnt/data/ (as in config.php)	/mnt/data/admin/files/keepass/personal.kdbx

$base_path is extracted from system config, which is set by the admin manually, so str_replace($base_path . '/', '', $path) fails to handle the situation where the base path already ends with a slash. The proposed change is to use realpath to sanitize the path before doing a string replace:

 $base_path = realpath($this->config->getSystemValue('datadirectory'));
 $path = Filesystem::getLocalFile(Filesystem::getPath($nodeID));
 $command = str_replace('%n', escapeshellarg(str_replace($base_path . '/', '', $path)), $command);

By the way, the documentation for the %n placeholder gives an example alice/files/Pictures/Wonderland/20180717_192103.jpg which does not start with a slash. However, the previous behaviour of this app before #64 since the very first commit does replace %n with a path starting with /. My scripts have always worked with inputs such as /admin/files/keepass/personal.kdbx. After #64, any existing scripts that rely on this bug will be affected.

@it25fg Could you please test the proposed fix?

[steini86]

Had a script that relied on this bug and was be affected. I remember that it took me quite some time in the beginning to figure out the path actually started with a slash. Now it stopped working and thanks to your post I could easily solve it by adding the now missing slash to my path. Would not have needed this hassle if I could get a real full path to the file as a placeholder.

[blizzz]

That was fixed in #81