Implement new access API for projects

[stgraber]

It would be nice to have a /1.0/projects/NAME/access endpoint which one could GET to retrieve the list of who's allowed access and what access level they have on the object.

[sharathsivakumar]

Hey @stgraber I would like to work on this!

[stgraber]

I'm currently giving priority for those easier issues to the students at the University of Texas in Austin as they've literally ran out of things to work on but I'll happily assign you to this one if they don't claim it in the next week :)

[j2walker]

Hi @stgraber, I'm with the Virtualization class at UT Austin, could I work on this issue?

[stgraber]

Yep, assigned it to you

[j2walker]

Hi @stgraber, I am beginning to work on this issue and have read your comments on #725. I found other API endpoints for /1.0/projects/{name} in /cmd/incusd/api_project.go, so I'm assuming that is where this new GET endpoint will go. Since we will be sharing the same access struct, I'll just reach out to my classmate to get their struct code so it's consistent between the two PRs.

I'm assuming the internal logic will be slightly different since this endpoint will be querying the projects for access instead of instances, but should it be something like GetProjectAccess(ctx context.Context, projectName string) (*api.Access, error) in internal/server/auth/access.go?

Then would checking access be the same as you've outlined in #725 where you check the certificate level?

[stgraber]

Hi @stgraber, I am beginning to work on this issue and have read your comments on #725. I found other API endpoints for /1.0/projects/{name} in /cmd/incusd/api_project.go, so I'm assuming that is where this new GET endpoint will go. Since we will be sharing the same access struct, I'll just reach out to my classmate to get their struct code so it's consistent between the two PRs.

Yep, that's the correct location for it.

I'm assuming the internal logic will be slightly different since this endpoint will be querying the projects for access instead of instances, but should it be something like GetProjectAccess(ctx context.Context, projectName string) (*api.Access, error) in internal/server/auth/access.go?

Yep, that's correct and the check itself in the case of the tls driver should be basically identical to that for instance access given that the instance access logic in the case of the tls driver doesn't actually do anything with the instance name.