Server: OCS API user info returns incomplete data

[dampfklon]

Steps to reproduce

1. Request Userinfo via OCS API https://example.com/ocs/v1.php/cloud/users/USERID

Expected behaviour

Correct info like doku https://docs.nextcloud.com/server/13/admin_manual/configuration_user/instruction_set_for_users.html

Actual behaviour

broken info (quota, email, groups) same for ocs/v1.php/cloud/users/USERID/groups

<?xml version="1.0"?>
<ocs>
 <meta>
  <status>ok</status>
  <statuscode>100</statuscode>
  <message>OK</message>
  <totalitems></totalitems>
  <itemsperpage></itemsperpage>
 </meta>
 <data>
  <enabled>true</enabled>
  <id>USERID</id>
  <quota/>
  <email/>
  <displayname>Username</displayname>
  <phone></phone>
  <address></address>
  <website></website>
  <twitter></twitter>
  <groups/>
  <language></language>
 </data>
</ocs>

Server configuration

Operating system:

Web server: Apache 2.2.15

Database: MySQL 5.1.73

PHP version: 7.1.16

Nextcloud version: 13.0.2

Updated from an older Nextcloud/ownCloud or fresh install: Update

Where did you install Nextcloud from: zip

Signing status:

Signing status

No errors have been found.

List of activated apps:

App list

Enabled:
  - bruteforcesettings: 1.0.3
  - calendar: 1.6.1
  - contacts: 2.1.3
  - dav: 1.4.6
  - federatedfilesharing: 1.3.1
  - files: 1.8.0
  - files_external: 1.4.1
  - files_pdfviewer: 1.2.1
  - files_sharing: 1.5.0
  - files_texteditor: 2.5.1
  - files_trashbin: 1.3.0
  - files_videoplayer: 1.2.0
  - gallery: 18.0.0
  - logreader: 2.0.0
  - lookup_server_connector: 1.1.0
  - nextcloud_announcements: 1.2.0
  - notifications: 2.1.2
  - oauth2: 1.1.0
  - password_policy: 1.3.0
  - piwik: 0.4.1
  - polls: 0.8.1
  - provisioning_api: 1.3.0
  - richdocuments: 2.0.8
  - serverinfo: 1.3.0
  - sharebymail: 1.3.0
  - twofactor_backupcodes: 1.2.3
  - updatenotification: 1.3.0
  - workflowengine: 1.3.0
Disabled:
  - activity
  - admin_audit
  - comments
  - encryption
  - federation
  - files_versions
  - firstrunwizard
  - survey_client
  - systemtags
  - theming
  - user_external
  - user_ldap

Nextcloud configuration:

Config report

 {
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "skeletondirectory": "\/var\/www\/virtual\/xxx\/skeleton",
        "dbtype": "mysql",
        "version": "13.0.2.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "versions": "false",
        "loglevel": 0,
        "log_rotate_size": 52428800,
        "forcessl": true,
        "blacklisted_files": [
            ".htaccess"
        ],
        "default_language": "de",
        "defaultapp": "files",
        "knowledgebaseenabled": false,
        "xframe_restriction": true,
        "maintenance": false,
        "apps_paths": [
            {
                "path": "\/var\/www\/virtual\/xxx\/html\/apps",
                "url": "\/apps",
                "writable": true
            }
        ],
        "theme": "xxx",
        "trusted_domains": [
            "***REMOVED SENSITIVE VALUE***"
        ],
        "secret": "***REMOVED SENSITIVE VALUE***",
        "share_folder": "\/",
        "mail_smtpmode": "php",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 0
        },
        "htaccess.RewriteBase": "\/",
        "upgrade.disable-web": true,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "***REMOVED SENSITIVE VALUE***",
        "appstoreenabled": true,
        "appstoreurl": "https:\/\/api.nextcloud.com\/v1"
    }
}

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

Are you using encryption: no

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

Client configuration

Browser: curl

Operating system: ubuntu 18.04

Logs

Web server error log

Web server error log

none

Nextcloud log (data/nextcloud.log)

Nextcloud log

none

[dampfklon]

I have some more information if you request the user in correct case you get correct information, if you request the user in wrong case eg. username instead UserName you get broken info as shown above.
I also verfied this on a fresh nextcloud 13.0.2 install

[rullzer]

@skjnldsv can you have a look?

[skjnldsv]

@rullzer this is on 13, we did not do any changes on 13 iirc :/

[rullzer]

@skjnldsv sure just see if it also does this on 14 and if so fix there ;)

[skjnldsv]

@dampfklon Are you talking about the self closing elements?
If so this is the proper behavior:

See the W3C specs for XML and XHTML:

http://www.w3.org/TR/xml/#sec-starttags
http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict
It depends on the Element Type declaration

An element with no content is said to be empty. The representation of an empty element is either a start-tag immediately followed by an end-tag, or an empty-element tag.

but also

Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY. For interoperability, the empty-element tag SHOULD be used, and SHOULD only be used, for elements which are declared EMPTY.

Regarding the quota, it is fixed in 14 (see #8926 )

[dampfklon]

@skjnldsv No I was referring to the missing quota, mail, group, language,... info, as all of the information is present in the request with correct case. Its not related to the referenced issue as the user has already initialized.
The request above with correct case lead to following response

<?xml version="1.0"?>
<ocs>
 <meta>
  <status>ok</status>
  <statuscode>100</statuscode>
  <message>OK</message>
  <totalitems></totalitems>
  <itemsperpage></itemsperpage>
 </meta>
 <data>
  <enabled>true</enabled>
  <id>USERID</id>
  <quota>
   <free>5368709120</free>
   <used>0</used>
   <total>5368709120</total>
   <relative>0</relative>
   <quota>5368709120</quota>
  </quota>
  <email>REMOVED SENSITIVE VALUE</email>
  <displayname>Username</displayname>
  <phone></phone>
  <address></address>
  <website></website>
  <twitter></twitter>
  <groups>
   <element>Group1</element>
   <element>Group2</element>
   <element>Group3</element>
   <element>Group4</element>
  </groups>
  <language>de_DE</language>
 </data>
</ocs>

[skjnldsv]

Thanks for your answer :)
I'm not sure I get it correctly. Can you confirm that the user in the first example has an email set, belong to groups and/or has been logged in at least once?

[dampfklon]

Correct I query the same user, which has an email set, belong to groups and has been logged in multiple times. The username is eg. Dampfklon if i query ocs/v1.php/cloud/users/dampfklon i get the data from the first example if I query ocs/v1.php/cloud/users/Dampfklon i get the response from the second example

[skjnldsv]

Thanks. I will take a look :)

[rullzer]

Aaaah well then it actually makes sense. The userid is case sensitive. That is works for some of the info is because the basic backend is not case sensitive. So the bug would be that we display info if the case does not match exactly ;)

When using the API you should always use to correct userid.