Error logged when creating a new share

[klada]

I am getting the following errors in my NextCloud server log when creating a new share:

[ERROR] -- 2017-03-08 10:19:08+01:00 --
[ERROR] PUT /ocs/v2.php/apps/files_sharing/api/v1/shares/3716?format=json
[ERROR] User: 'klada'@'192.168.1.8'
[ERROR] $params["date"] was missing. Transferred value: Array
(
    [itemType] => file
    [itemSource] => 377423
    [date] => 
    [uidOwner] => klada
)

Apache log

192.168.1.8 - - [08/Mar/2017:10:19:08 +0100] "PUT /ocs/v2.php/apps/files_sharing/api/v1/shares/3716?format=json HTTP/1.1" 200 750 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36" 0

The share itself is working, it's just a nasty error in the log.

Steps to reproduce:

1. Click on the "Share" button
2. Tick "Share by link"
3. Remove the option "Set expiredate" (an expire date is set by default for all shares in my instance)

NextCloud version: 11.0.2

[MorrisJobke]

cc @schiessle @rullzer

[rullzer]

Mmm I can't reproduce this.

But what I find most strange is that the date field is not even correct. It should be expireDate. And the rest should not be send with it.

Can you check your browser console what the actual PUT request is?

[klada]

This is the actual PUT XHR body:

{
    "headersSize": 1401,
    "bodySize": 11,
    "postData": {
        "mimeType": "application/x-www-form-urlencoded; charset=UTF-8",
        "text": "expireDate=",
        "params": [
            {
            "name": "expireDate",
            "value": ""
            }
        ]
    }
}

And it can also be reproduced without an expiration date policy in Nextcloud 11.0.2:

1. Create a new share by link
2. Enable expire date and set any date
3. Disable expire date again → this is when the error shows up in the log

[rullzer]

I still don't get a warning in my logs... @schiessle can you give this a go?

[klada]

Sorry guys, I forgot to mention that this error is logged by admin_audit 🤦‍♂️ . So the admin_audit log app needs to be enabled in order to reproduce this.

So this is probably a bug in admin_audit...

[skjnldsv]

As there is no feedback since a while I will close this ticket. If this is still happening please feel free to reopen.