Come creare il controllo accessi a livello di record sulle entità derivate?

Sembra che tu stia affrontando una cosa Authorization , piuttosto che un controllo di accesso. È più simile, anche se un utente è autorizzato a creare / leggere / aggiornare / eliminare una risorsa (controllo degli accessi), dovrebbe essere in grado di farlo da solo (autorizzazione).

Questo può essere implementato con qualcosa di semplice come un middleware che controlla se l'utente in sessione possiede la risorsa (o il genitore della risorsa). A seconda di questo controllo, restituirai la risorsa con 200 o 403 . In parole più tecniche, si farebbe un if (session.user.id == task.user_id) o if (session.user.id == document.task.user_id) .

Se stai lavorando con un framework MVC che supporta il middleware o il callback del ciclo di vita pre-azione, puoi farlo in entrambi. Altrimenti potresti usare il gestore degli eventi di framework per fare quel controllo prima che la richiesta arrivi al controller. Nel peggiore dei casi, metti il segno di spunta all'interno dell'azione del controllore.

Il requisito

Capisco che tu voglia consentire agli utenti di accedere / aggiornare i propri documenti, cioè i documenti relativi alle attività che possiedono:

    +----------+         +----------+         +----------+
    |          |        n|          |        n|          |
    |   User   |---------|   Task   |---------| Document |
    |          |1        |          |1        |          |
    +----------+         +----------+         +----------+

Quindi per controllare l'accesso alle richieste, è necessario in qualche modo avere informazioni sulla proprietà dell'utente. E lo stesso per documenti con compiti.

Si noti che qui c'è una piccola ambiguità: l'attività è di proprietà di un singolo utente (sì: il proprietario può essere salvato con l'attività, no: la proprietà deve essere archiviata in una tabella separata)? E i documenti sono legati ad un singolo compito? Ma questo non cambia fondamentalmente il problema del controllo degli accessi.

Opzione 1: l'endpoint del documento viene gestito sullo stesso server dell'endpoint dell'attività

Implementare il servizio per accedere al database comune che unisce le tabelle pertinenti. Il tuo RDBMS e il suo ottimizzatore gestiranno questo senza dolore.

Opzione 2: hai microservizi indipendenti

Implementare alcune repliche, in modo che ogni volta che viene modificata la proprietà di un'attività, le informazioni sulla proprietà vengano propagate al servizio documenti. È possibile elaborare l'aggiornamento tramite aggiornamento o offrire un'API per l'aggiornamento periodico di massa.