greenbone / gvmd

Greenbone Vulnerability Manager - The database backend for the Greenbone Community Edition
GNU Affero General Public License v3.0
286 stars 153 forks source link

get_targets: Missing pagination option #1873

Closed fahn closed 1 year ago

fahn commented 2 years ago

Expected behavior

If you specify more than 10 targets, then you should get the option to get via <get_targets /> all of them in the list function as well.

Actual behavior

Actually you only get 10 targets. No other targets are displayed after using the command <get_target />:

<get_targets_response status="200" status_text="OK">
    <target id="0c7d9ee1-8e1e-4a87-8efd-a3d4311a92a2">
        ...
    </target>
    <target id="39401cfd-a7e9-4dcf-9466-27a39ec91199">
        ...
    </target>
    <target id="fdc1de72-d722-4bdb-b7b7-246f94d423b5">
        ...
    </target>
    <target id="7cf778fd-cf17-4aea-af59-ba3f671a8ada">
        ...
    </target>
    <target id="a511a5d4-cb00-44f7-82ec-1b83fa654641">
        ...
    </target>
    <target id="d8331b80-09d6-461b-9dc6-b3a987e9f92c">
        ...
    </target>
    <target id="d5713f88-7d97-403c-8e6e-81fe91aca595">
        ...
    </target>
    <target id="b316af36-049a-4626-a9f9-33afce90d75e">
        ...
    </target>
    <target id="a6c4424a-6d60-4ed7-bcd9-4fd4d01c462a">
        ...
    </target>
    <target id="c61f5c65-3524-4b9d-83d2-f542fdd97ad8">
        ...
    </target>
    <filters id="">
        <term>first=1 rows=10 sort=name</term>
        <keywords>
            <keyword>
                <column>first</column>
                <relation>=</relation>
                <value>1</value>
            </keyword>
            <keyword>
                <column>rows</column>
                <relation>=</relation>
                <value>10</value>
            </keyword>
            <keyword>
                <column>sort</column>
                <relation>=</relation>
                <value>name</value>
            </keyword>
        </keywords>
    </filters>
    <sort>
        <field>name<order>ascending</order>
        </field>
    </sort>
    <targets start="1" max="1000"/>
    <target_count>33<filtered>33</filtered>
        <page>10</page>
    </target_count>
</get_targets_response>

Unfortunately, you only get 10 targets, although 33 were created here! If you call one directly with the uuid, which is not in the list, you get here also a correspondingly correct result. According to the documentation , there is for example with <get_tasks /> the possibility to eliminate the pagination. It would be advisable to enable this here too.

Steps to reproduce

  1. Create more then 10 Targets
  2. Request <get_targets /> and see, that are only 10 are visible

GVM versions

gvm: Greenbone Vulnerability Manager 22.4.0~dev1

openvas-scanner: OpenVAS 22.4.1~dev1

Environment

Operating system: Linux 5.4.0-131-generic #147-Ubuntu SMP Fri Oct 14 17:07:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Installation method / source: official docker container

bjoernricks commented 1 year ago

The pagination can be done in nearly all queries via the filter attribute using the rows and first keywords. For example

<get_targets filter="rows=100 first=101"/> will return the targets 101 to 200. At maximum 1000 items can be requested in one query.

fahn commented 1 year ago

Ok, if I want to get all Targets, then I have to use this command, right? <get_targets filter="rows=999999 first=1"/>

Why do you allow pagination to be turned off on other requests and here you only offer a max of 10 entries? Makes more sense, if you offer the same command to all requests like get_targets!

bjoernricks commented 1 year ago

No you have to use pagination. You can set rows to 999999 but you wont get more then 1000 items as I wrote in my last response.

And yes of course it would make sense to use the same patterns everywhere but as always this has historical reasons. Just take a look at GitHub's REST API and you will find similar issues.

fahn commented 1 year ago

I dont know, why I have to look at issues from different publishers, but for me its okay.

y0urself commented 1 year ago

This is no issue, @bjoernricks wanted to mention, that this pattern is a normal thing for APIs, you will always have pagination and can't get all e.g. thousands of entries at once.

Why would you even filter for 999999 rows, if you only have 33 targets.

fahn commented 1 year ago

I also don't have a problem with this "solution". I only want to report, that your interfaces are working completely different(max. 10 rows against infinity rows).

bjoernricks commented 1 year ago

And I wrote that differently working interfaces are also very common. Even on this very puplic platform with thousands of users.

y0urself commented 1 year ago

I also don't have a problem with this "solution". I only want to report, that your interfaces are working completely different(max. 10 rows against infinity rows).

Noone said, that there is a max. of 10 rows in the API.

bjoernricks commented 1 year ago

To summarize there is an API to requests more then 10 targets. You have to use a filter string for this. To get all targets (and all other items besides tasks) you need to use pagination. You can get at maximum 1000 items in one requests for example <get_targets filter="rows=1000 first=1"/>. Yes the API has some quirks and we are aware of them. This has historical reasons and wont go away in near future. Also there will be no API for getting all items in one request. You will always have to use pagination.