Getting the compute resources of a plugin requires authorization

[jennydaman]

It would be preferable for it to be possible to get the compute resources of a plugin without authorization.

[jbernal0019]

@jennydaman @rudolphpienaar I'm not sure it's a good idea to make the information about compute resources publicly available (i.e. to internet users that are not logged in to ChRIS). It's a further invitation to attacks. @rudolphpienaar let me know if you want this to be enabled. Hare is a current example response:

HTTP/1.1 200 OK
Allow: GET
Content-Length: 743
Content-Type: application/vnd.collection+json
Cross-Origin-Opener-Policy: same-origin
Date: Fri, 16 Jan 2026 23:19:42 GMT
Referrer-Policy: same-origin
Server: WSGIServer/0.2 CPython/3.12.11
Vary: Accept, origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

{
    "collection": {
        "href": "http://localhost:8000/api/v1/plugins/1/computeresources/",
        "items": [
            {
                "data": [
                    {
                        "name": "id",
                        "value": 1
                    },
                    {
                        "name": "creation_date",
                        "value": "2026-01-16T18:16:46.741365-05:00"
                    },
                    {
                        "name": "modification_date",
                        "value": "2026-01-16T18:16:46.741374-05:00"
                    },
                    {
                        "name": "name",
                        "value": "host"
                    },
                    {
                        "name": "compute_url",
                        "value": "http://pfcon.remote:30005/api/v1/"
                    },
                    {
                        "name": "compute_auth_url",
                        "value": "http://pfcon.remote:30005/api/v1/auth-token/"
                    },
                    {
                        "name": "compute_innetwork",
                        "value": true
                    },
                    {
                        "name": "description",
                        "value": "host Description"
                    },
                    {
                        "name": "max_job_exec_seconds",
                        "value": -1
                    }
                ],
                "href": "http://localhost:8000/api/v1/computeresources/1/"
            }
        ],
        "links": [
            {
                "href": "http://localhost:8000/api/v1/plugins/1/",
                "rel": "plugin"
            }
        ],
        "total": 1,
        "version": "1.0"
    }
}

[rudolphpienaar]

Ordinarily I would also argue that getting the compute resources of a plugin w/o authorization is fine and useful, but I am trying to be more security conscious. @jennydaman -- since I view your "sec-dar" as better than mine, I'm curious what you think? I suppose it depends on how "rich" a return one gets w/o authorization? Being able to see maybe just the resource "name" w/o detail about URLs etc is a good compromise for non-auth cases?

[jennydaman]

In principle, Jorge is right but principle is meaningless without a proper threat model. I think I originally created this issue because I was imagining some updates to ChRIS_ui where there can be fancy display of which plugins are registered to what compute resources, which compute resources are most popular, current utilization of compute resource, ... We've agreed upon having a vision where ChRIS_ui (specifically app.chrisproject.org) would have an "eye-catching" and rich experience for anonymous users who would be able to browse ChRIS without logging in and see example datasets and exemplar feeds. Putting APIs behind authorization without regard for threat model and product goals is just making our own jobs harder.

@rudolphpienaar I agree, compute_url and compute_auth_url should be hidden (in the same way compute_password and compute_auth_token are hidden) but everything else should remain public.