Implement Hitobito event access control

[eliaSchenker]

This is a shared access control flow, used by multiple endpoints, to check whether a user has access to a Hitobito event they are trying to access.

Implementation

1. Retrieve event participations from the Hitobito API, filtering by the specified event id, and the user id

   GET <base-url>/api/event_participations
   ?include=roles
   &filter[participant_id][eq]=<hitobito_user_id>
   &filter[event_id][eq]=<eventId>
   &fields[event_participations]=active
   &fields[event_roles]=type
   

   Example Response:

   {
     "data": [
   	{
   	  "id": "16904",
   	  "type": "event_participations",
   	  "attributes": {
   		"active": true
   	  },
   	  "relationships": {
   		// ...
   		"roles": {
   		  "data": [
   			{
   			  "type": "event_roles",
   			  "id": "17996"
   			}
   		  ]
   		}
   	  }
   	}
     ],
     "included": [
   	{
   	  "id": "17996",
   	  "type": "event_roles",
   	  "attributes": {
   		"type": "Event::Camp::Role::Leader"
   	  },
   	  "relationships": {
   		"participation": {
   		  "meta": {
   			"included": false
   		  }
   		}
   	  }
   	}
     ],
     "links": { /* ... */ },
     "meta": {}
   }

2. Make sure that one of the included roles has one of the following attributes.type
   • Event::Camp::Role::Leader
   • Event::Role::Leader
   • Event::Course::Role::Leader
3. If no event / event participations are found, respond with 404 Not Found
4. If an event is found but the role is not present or the participation has active = false, respond with 403 Forbidden

Implementation Note: Make sure that the role that identifies a user as a leader of an event (for MiData Event::Camp::Role::Leader) is configurable per different Hitobito provider, so that new supported instances (i.e. CeviDB) can be easily added in the future.
Defined roles should be shared with #10386

[BacLuc]

Is this a change of the hitobito api?

[carlobeltrame]

No, it enforces the eCamp-side access control rule "only hitobito event leaders may link an eCamp camp to the hitobito event". Hitobito knows nothing about eCamp, so this is implemented in eCamp.

[BacLuc]

Ok. this might be a rough draft. I still want to hint to the query parameter pattern api platform generates:
https://dev.ecamp3.ch/api/index.jsonhal

e.g. the schedule_entries endpoint:

{
  "periods": {
    "href": "\/api\/periods{\/id}{?camp,camp[],campCollaborator}",
    "templated": true
  },
  "profiles": {
    "href": "\/api\/profiles{\/id}{?user.collaborations.camp,user.collaborations.camp[],user,user[],search}",
    "templated": true
  },
  "scheduleEntries": {
    "href": "\/api\/schedule_entries{\/id}{?period,period[],activity,activity[],start[before],start[strictly_before],start[after],start[strictly_after],end[before],end[strictly_before],end[after],end[strictly_after]}",
    "templated": true
  }
}

[carlobeltrame]

Ok. this might be a rough draft. I still want to hint to the query parameter pattern api platform generates:
https://dev.ecamp3.ch/api/index.jsonhal

e.g. the schedule_entries endpoint:

{
  "periods": {
    "href": "\/api\/periods{\/id}{?camp,camp[],campCollaborator}",
    "templated": true
  },
  "profiles": {
    "href": "\/api\/profiles{\/id}{?user.collaborations.camp,user.collaborations.camp[],user,user[],search}",
    "templated": true
  },
  "scheduleEntries": {
    "href": "\/api\/schedule_entries{\/id}{?period,period[],activity,activity[],start[before],start[strictly_before],start[after],start[strictly_after],end[before],end[strictly_before],end[after],end[strictly_after]}",
    "templated": true
  }
}

I may be missing something, but in this issue, I thought eCamp code interacts with the hitobito API. The eCamp API is not involved here, and neither hitobito's code nor its API need to be modified. The payloads in the issue description are the way hitobito outputs them already.

[eliaSchenker]

@carlobeltrame You are right, this issue does not define an eCamp endpoint. The new eCamp API endpoints call the Hitobito API. This issue defines how we check in an eCamp API endpoint that the user is allowed to perform an action on a referenced Hitobito event. The concrete issues that specify the new endpoints reference this issue (to avoid repeating the same check in each specification, I split this up). When making calls to Hitobito, I always included the response model that Hitobito returns, so that it's clear what needs to be processed by the eCamp API. No changes are made to the Hitobito API.

Please let me know if the issue description need some adjustments to make this more clear.

[carlobeltrame]

It seems clear enough to me, but maybe @BacLuc can give us some input on how to clear up the misunderstanding.

One nitpick suggestion could be: When you are talking about business logic of eCamp calling the external hitobito API, it might be clearer if instead of saying "the endpoint calls the hitobito API" you say "the backend calls the hitobito API". Of course the logic on the eCamp side is triggered by a call to the eCamp API, and we normally always call our backend code api. But in this context it might just be marginally clearer to indicate which way the relevant HTTP request is going.