Endpoint collections-search/{collection-id} does not work

[YuriZmytrakov]

Describe the bug
Currently, there is no collection-search/{collection-id} endpoint implemented. As a result, it’s not possible to query a single collection through the collections-search endpoint. When attempting to request a specific collection using this route, the API returns an error: {"detail": "Not Found"}
Since the collections/{collection-id} endpoint does not support filters, it’s not possible to restrict user access or limit searches by collection IDs. This means users can still attempt to access collections they don’t have permission for.

Expected behavior
The response should be similar to collections/{collection-id}

[jonhealy1]

I envisioned the /collections-search endpoint as being a for collections version of the /search endpoint which caters to Items. If we add this, then we have to add numerous more api routes which we don't need, because we can just use the /collections route which already exists. /collections-search primarily provides POST search functionality for STAC collections, for Users who can't use POST /collections because they have the Transaction extension enabled, which uses the same route to POST new collections to the database.

[jonhealy1]

Reopen if needed

[Gomez324]

@jonhealy1 When a user makes a query to an endpoint like /collections/{id} or /collections/{collection_id}/items/{item_id}, we have a stac-auth-proxy in front of sfeos that adds to the request the collections/items the user has access to. So when they ask for a single collection or single product, even though they shouldn't have access, they could still see it because there's no collections search and items search on those endpoints. I reopened it because it's quite an important matter for me.

[jonhealy1]

Hi @Gomez324. Can you give more of an explanation? You can still do a GET search on the /collections endpoint. You can also do a POST search on the same endpoint if the Transactions Extension is disabled.

ie. /collections?q=landsat

[Gomez324]

@jonhealy1

example: User X has access only to collections A and B.

When using the /collections? endpoint (search), the auth proxy automatically restricts the results to only collections A and B that the user has permissions for. Collections C, D, etc. won't be visible. This works correctly.
However, the problem emerges with the /collections/{collection-id} endpoint:
This endpoint allows direct access to a specific collection by its ID. Because there's no implementation of a collection-search mechanism (collection filtering), the proxy cannot add a filter to restrict access. As a result, user X can directly enter the ID of collection C, D, or any other collection and gain access to it, even though they shouldn't have access.

[jonhealy1]

@Gomez324 @YuriZmytrakov Hi. I read the original question again. I'm puzzled by this statement "Since the collections/{collection-id} endpoint does not support filters". It should support the same filters as the /collections-search endpoint?

[jonhealy1]

I don't understand how a /collections-search/{collection-id} endpoint solves any problems I guess.

[Gomez324]

@jonhealy1

I mean something like this: the user should be able to make a query such as collections-search/sentinel-2-l2a or collections/sentinel-2-l2a (I’m not sure which option would be more correct here), and the proxy in front of SFEOS could attach a filter, for example: filter=id in (sentinel-2-l1c, sentinel-1-grd).

So the final query would look like this:
collections/sentinel-2-l1c?filter=id in (sentinel-2-l1c, sentinel-1-grd).

This means the user won’t find the collection they are asking for, because it wasn’t added by the proxy (since they shouldn’t have access to it). And what I mean is that right now it’s not possible to add this kind of filter to that endpoint.

[jonhealy1]

If we add anything like this it would have to be on the /collections-search route as the /collections route is governed by the stac-api spec which does not having anything similar to what you are suggesting. The /collections-search route is a custom route we added which exists outside of the stac-api spec. https://github.com/radiantearth/stac-api-spec

[Gomez324]

I understand. But it would be useful to have some mechanism for limiting searches that the user could impose themselves. What do you think about the option of passing a collection/geometry intersection through a header and applying it to the query?

[jonhealy1]

If it's an optional feature it makes sense I think.