search

a-schild / nextcloud-java-api

Java api library to access nextcloud features from java applications
GNU General Public License v3.0
72 stars 50 forks source link

added request for a list of user details #58

Closed kriszman closed 3 years ago

a-schild commented 3 years ago

After merging our PR, I receive this in the tests...

Tests run: 22, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.089 sec <<< FAILURE!
t02_01_testGetUsersDetails(org.aarboard.nextcloud.api.TestUserGroupAdmin)  Time elapsed: 0.452 sec  <<< ERROR!
org.aarboard.nextcloud.api.exception.NextcloudApiException: java.util.concurrent.ExecutionException: org.aarboard.nextcloud.api.exception.NextcloudApiException: javax.xml.bind.UnmarshalException
 - with linked exception:
[org.xml.sax.SAXParseException; lineNumber: 262; columnNumber: 2; Markup im Dokument nach dem Root-Element muss ordnungsgemäß formatiert sein.]
kriszman commented 3 years ago

Strange, of course I've been running these tests against nextcloud (v20 and v21)... which version have you been using for your tests? maybe the schema changed? I'll have look at it

a-schild commented 3 years ago

I tested it agains 21.0.1 and 21.0.2. Here what I get as response from the server, I think it may be the backend and backendCapabilities tag causing problems. That instance is using LDAP as user backend

<?xml version="1.0"?>
<ocs>
 <meta>
  <status>ok</status>
  <statuscode>100</statuscode>
  <message>OK</message>
  <totalitems></totalitems>
  <itemsperpage></itemsperpage>
 </meta>
 <data>
  <users>
   <enabled>1</enabled>
   <storageLocation>/xxxxxxxxxxxxxxxx/1f16f2f6-2a83-1038-8bad-231f8c42b887</storageLocation>
   <id>xxxxxxxxxxxxxxxxx</id>
   <lastLogin>1541777750000</lastLogin>
   <backend>LDAP</backend>
   <subadmin/>
   <quota>
    <free>219261231104</free>
    <used>10610753</used>
    <total>219271841857</total>
    <relative>0</relative>
    <quota>350039834624</quota>
   </quota>
   <email>xxx@aarboard.ch</email>
   <displayname>xxxx</displayname>
   <phone></phone>
   <address></address>
   <website></website>
   <twitter></twitter>
   <groups>
    <element>users</element>
    <element>Aarboard</element>
   </groups>
   <language>de</language>
   <locale></locale>
   <backendCapabilities>
    <setDisplayName></setDisplayName>
    <setPassword></setPassword>
   </backendCapabilities>
  </users>
</data>
</ocs>
kriszman commented 3 years ago

ok, I quickly fired the request against v18 to v21, this is what it should look like:

<?xml version="1.0"?>
<ocs>
    <meta>
        <status>ok</status>
        <statuscode>100</statuscode>
        <message>OK</message>
        <totalitems></totalitems>
        <itemsperpage></itemsperpage>
    </meta>
    <data>
        <users>
            <admin>
                <enabled>1</enabled>
                <storageLocation>/var/www/html/data/admin</storageLocation>
                <id>admin</id>
                <lastLogin>1621586168000</lastLogin>
                <backend>Database</backend>
                <subadmin/>
                <quota>
                    <free>45053579264</free>
                    <used>16913831</used>
                    <total>45070493095</total>
                    <relative>0.04</relative>
                    <quota>-3</quota>
                </quota>
                <email/>
                <displayname>admin</displayname>
                <phone></phone>
                <address></address>
                <website></website>
                <twitter></twitter>
                <groups>
                    <element>admin</element>
                </groups>
                <language></language>
                <locale></locale>
                <backendCapabilities>
                    <setDisplayName>1</setDisplayName>
                    <setPassword>1</setPassword>
                </backendCapabilities>
            </admin>
        </users>
    </data>
</ocs>

it seems like there's something wrong with xml schema in case nextcloud uses ldap as the backend provider, at least in your example there are no user id tags... I'll try to quickly check against a ldap instance

kriszman commented 3 years ago

ok, so this the result of a test against a ldap instance (v20.0.8):

<?xml version="1.0"?>
<ocs>
    <meta>
        <status>ok</status>
        <statuscode>100</statuscode>
        <message>OK</message>
        <totalitems></totalitems>
        <itemsperpage></itemsperpage>
    </meta>
    <data>
        <users>
            <element>
                <enabled>1</enabled>
                <storageLocation>*****</storageLocation>
                <id>*****</id>
                <lastLogin>0</lastLogin>
                <backend>LDAP</backend>
                <subadmin/>
                <quota>
                    <quota>*****</quota>
                    <used>0</used>
                </quota>
                <email>*****</email>
                <displayname>*****</displayname>
                <phone></phone>
                <address></address>
                <website></website>
                <twitter></twitter>
                <groups>
                    <element>*****</element>
                </groups>
                <language>de_DE</language>
                <locale></locale>
                <backendCapabilities>
                    <setDisplayName></setDisplayName>
                    <setPassword></setPassword>
                </backendCapabilities>
            </element>
            <admin>
                <enabled>1</enabled>
                <storageLocation>*****</storageLocation>
                <id>admin</id>
                <lastLogin>*****</lastLogin>
                <backend>Database</backend>
                <subadmin/>
                <quota>
                    <free>*****</free>
                    <used>*****</used>
                    <total>*****</total>
                    <relative>0.04</relative>
                    <quota>-3</quota>
                </quota>
                <email/>
                <displayname>admin</displayname>
                <phone></phone>
                <address></address>
                <website></website>
                <twitter></twitter>
                <groups>
                    <element>admin</element>
                </groups>
                <language>de_DE</language>
                <locale></locale>
                <backendCapabilities>
                    <setDisplayName>1</setDisplayName>
                    <setPassword>1</setPassword>
                </backendCapabilities>
            </admin>
        </users>
    </data>
</ocs>

so it seems like LDAP users are encapsulated within <element> subtags in contrast to standard users provided by the Database backend. However, the Unit Test that seems to fail on your side finishes successfully on my side in this case as well... so I'm not really sure what's going wrong there on your side, but I guess the reason for your issues must be the missing subtags like <element> or <admin>, at least the don't show up in the example you provided earlier.

kriszman commented 3 years ago

I also ran another test against v21.0.1 with ldap as the user backend provider without any issues. So for now I'm not quite sure what else to do about it...

kriszman commented 3 years ago

Hi!

I wanted to ask if you're going to take my latest enhancements into the next official release? The point is that I would need them in one of my projects, but unfortunately you didn't respond anymore to the discussion we had in May regarding some test issues you had. Hope we can fix that together! Thx a lot!

a-schild commented 3 years ago

I will try again with a new Nextcloud instance in the next days

a-schild commented 3 years ago

It's a nextcloud bug causing invalid XML response, when you have users with non-xml allowed characters in the name. In my case, it breaks as soon as an user contains the @ character in the user id, and also breaks when it starts with a number

https://github.com/nextcloud/server/issues/20840

a-schild commented 3 years ago

A possible work arround is to:

  1. Send a request to get a list of the users (without details) /ocs/v1.php/cloud/users

  2. For each user send a separate request to retrieve the details /ocs/v1.php/cloud/users/myuser@mydomain.com

This will work, since the "single" response for the user details has a different xml structure, but the drawback is that we need n+1 requests to get all users

@kriszman Would you be willing to change the handling as mentioned above?

a-schild commented 3 years ago

The current nextcloud server api will not be fixed, due to missing versioning. Mentioned here: https://github.com/nextcloud/server/pull/20854

kriszman commented 3 years ago

Ok, these are rather bad news, because in fact I wanted avoid your provided workaround in the first place as I'm already using it and it simply requires too many unnecessary requests, however thx a lot for your investigations! Anyway, I've got another workaround trying to catch any unmarshalling exceptions and skipping the corresponding users within the final result list, see: https://github.com/a-schild/nextcloud-java-api/blob/42b469a39a3eaaa903a20a6e28ab1a16341f390a/src/main/java/org/aarboard/nextcloud/api/provisioning/UsersDetailsXMLAnswer.java#L24

a-schild commented 3 years ago

Nope, unfortunall this does not work, since the xml document sent by the server is already corrupt. You can create a NC user with @ in the name and then you see how it is breaking. Unfortunally there is no way to fix it on client side, only using the other API results in a working solution