Authorization on items with a big number of collections

[alambare]

Hello,

Thank you for all the work you put into this!

I am using eoAPI and need to provide fine-grained authorization on collections and items.

Using the filter expression seems perfectly valid, and I was able to get it working by specifying a collection filter and applying the same logic as in the example from the readme. I simply query the proxy's /collections endpoint to get the list of allowed collections.

However, this approach won't scale well as the number of collections increases in the catalog because of the URL size limit when using GET requests. What about having the proxy requesting the backend using POST method for item-search when the backend supports it?

But also, what if I have something like 10,000 collections in my catalog? The CQL2 request will become bloated with all the collections listed. I was wondering if this is a scenario you've already encountered, or if you have any thoughts on potential approach?

[alukach]

this approach won't scale well as the number of collections increases in the catalog because of the URL size limit when using GET requests.

This is a good point. To my knowledge, there is no standardized limit to URL size; the value depends on your backend API technology. Reading this thread, it sounds like Uvicorn + FastAPI has a URL limit of 65535 characters.

What about having the proxy requesting the backend using POST method for item-search when the backend supports it?

This sounds like a reasonable solution. Of course, there's probably also a limit on max size for POST bodies, but that's likely a much lesser problem.

what if I have something like 10,000 collections in my catalog? The CQL2 request will become bloated with all the collections listed.

Also true. For something like this, it would be ideal if the permissions could be generalized a bit (i.e. writing permissions against common properties rather than the individual collection IDs, such as private: true|false or owner: {ownerId}).

---

Before building a solution to avoid URL limits, I would like to hear that someone actually has this issue. It sounds largely theoretical in nature, at this point. In my experience, I have not come across many APIs with thousands of collections.

[alukach]

A note for any future implementors of this feature request: If we do swap GET requests for POST requests based on size, note that the response won't be exactly the same. For example, the link[rel=next] can differ based on request method. This may or may not be a big deal...

POST next link

{
  "rel": "next",
  "type": "application/geo+json",
  "method": "POST",
  "href": "http://localhost:8000/search",
  "body": {
    "filter": {
      "op": ">",
      "args": [
        {
          "property": "eo:cloud_cover"
        },
        90
      ]
    },
    "filter-lang": "cql2-json",
    "token": "next:hls2-l30:HLS.L30.T12TYL.2025148T174907.v2.0"
  }
}

GET next link

{
  "rel": "next",
  "type": "application/geo+json",
  "method": "GET",
  "href": "http://localhost:8000/search?filter=(\"eo:cloud_cover\"+>+90)&filter-lang=cql2-text&token=next:hls2-l30:HLS.L30.T12TYL.2025148T174907.v2.0"
}

[alambare]

Indeed, but that should ideally remain only between the proxy and the upstream STAC API and not be passed on to the client.

[alukach]

that should ideally remain only between the proxy and the upstream STAC API and not be passed on to the client.

Yes & no. I assume you're alluding to exposing the filters set internally (#64), which should be trimmed from the outgoing response (#67). However, the next links will definitely make their way to the client and the filters set in the next link should make their way to the client if they were provided by the user.

But I think the important callout is that we probably want to pay attention to transforming the next link from a method: POST to method: GET style link if we are automatically transforming requests from GET to POST to work around URL size restrictions.