Pensando a ruoli e permessi

Naviga le tue risposte
0

Sto creando una nuovissima applicazione Housing che consente all'utente di valutare o preferire le case. Di seguito sono riportati gli utenti dell'applicazione:

  1. proprietario

  2. Agente

  3. Ospite (non connesso)

  4. Visitatore (loggato)

  5. Tenant

Ora, Owner può eseguire CRUD operazioni, ma solo per la casa che possiede e non può valutare il House che possiede. Il Tenant ad esempio può R qualsiasi casa e può only valutare la casa che ha noleggiato.

Quindi, vedo lo schema qui; la prima è l'operazione CRUD che è roba di basso livello e alla fine qualsiasi logica di business si riduce a questa, la seconda è la logica di business stessa così, per esempio c'è una richiesta di rimuovere la casa da un utente e la richiesta è gestita da il seguente controller: 

// controller
function remove(req, res) {
  const { userId, houseId } = req.body;
  houseService.remove(userId, houseId);
  ...
}

// service
function add(userId, houseId) {
  const user = getUser(userId)
  if (user.hasRole(Roles.OWNER)) {
    // check if the houseId is one of the houses owned by the owner
    ...
  } else {
    throw AuthrorizationError();
  }
}

Sono un po 'confuso dai ruoli e dalla logica di business.

Domande:

  1. Il controllo dei permessi dovrebbe entrare in servizio o nel controller?
  2. Nell'esempio sopra sto verificando l'autorizzazione prima di eseguire qualsiasi logica di business, è corretto?
  3. La valutazione di una casa dovrebbe creare una nuova voce nella classifica association , dovrei aver esposto la classificazione come regola di autorizzazione agli utenti nel sistema i.e. CRUD operazione per ogni tipo di utente?

Aggiornamento:

Per essere più chiari su ratings posso avere le seguenti regole di permesso:

Tenant

Casa - sola lettura

Valutazione - Sì

proprietario

House - CRUD

Valutazione - Sì

Ma in qualche modo mi sta mettendo a disagio, dovrei nascondere le informazioni relative ai rating in profondità sotto la mia logica aziendale e non esporle a ruoli e permessi?

    
posta CodeYogi 14.12.2017 - 16:33
fonte

1 risposta

2

Permission checking should go in service or controller?

Il controllo dei permessi può andare nel controller, a meno che non sia conveniente reinserirlo nel servizio. È l'unica logica sostanziale che di solito inserisco in un controller e, quando lo faccio, è sempre un test "vai, non andare" (ad esempio, se il controllo delle autorizzazioni fallisce, l'intera operazione del controller fallisce).

In the example above I am checking permission before performing any business logic, is this correct?

Se il comportamento desiderato è impedire che l'operazione di business si verifichi se il chiamante non dispone delle autorizzazioni necessarie, allora sì, è necessario prima controllare le autorizzazioni.

Rating a house should create a new entry in rating association table, should I exposed rating as a permission rules to the users in the system i.e. CRUD operation for each user type?

Se con ciò intendi "dovrei avere un endpoint CRUD sulla mia API per creare record di associazione di rating", allora direi di no. Il tuo endpoint API dovrebbe esporre un sistema di valutazione; i record delle associazioni di rating possono essere creati internamente nella logica aziendale.

    
risposta data 14.12.2017 - 16:47
fonte

Leggi altre domande sui tag

Attivare non più di M eventi al secondo, simulare N incrementi al secondo Quanto profondo dovremmo esplorare il dominio (sottodominio, contesto limitato) in Domain Driven Design?