Decisione dell'architettura API sui livelli di autorizzazione e convalida

1

Stiamo progettando un meccanismo di autorizzazione per un'API di prodotto in cui gli utenti hanno le loro rivendicazioni.

L'API ha una richiesta di patch come questa:

PATCH https://product-fcd.com/api/product -d {"Products": []} -h "AuthToken":"xyz"

In questa richiesta, il processo si svolge in questo modo:

  • Convalida l'utente dal token, gestito da un middleware di autenticazione
  • Ottieni rivendicazioni utente, ottieni prodotti esistenti, controlla se l'utente ha l'autorizzazione per questi prodotti - gestito da un middleware di autorizzazione
  • Nel controller, ottieni i prodotti esistenti e li correggi in base all'input dell'utente. (l'utente non deve inserire tutti i campi di un prodotto)
  • Convalidare i prodotti internamente (ad esempio, BuyingPrice dovrebbe essere inferiore al SellingPrice) e, infine, aggiornarli.

Le entità:

Product:    
{
    "Id": "guid",
    "CategoryId": int,
    "Brand": "string",
    "SellingPrice": int,
    "BuyingPrice": int
}

UserClaims:    
{
    "UserId": "guid",
    "Claims":[
        {"CategoryId": 1, Access: true},
        {"CategoryId": 2, Access: false}
        {"CategoryId": 3, Access: true}
        {"Brand": "abc", Access: false}
    ]
}

Il problema è che il passaggio "Ottieni prodotti esistenti" è richiesto sia nella convalida delle attestazioni che nell'applicazione delle patch. Perché dovremmo controllare se l'utente ha diritto al prodotto e dovremmo controllare se lo stato più recente del prodotto è valido. Abbiamo pensato ad un modo in cui questo passaggio potesse essere gestito in un middleware separato e memorizzare i "Prodotti esistenti" nel contesto della richiesta, quindi passarlo dall'authortiontion al controller.

Puoi suggerire altri modi per gestirlo, oppure è una buona pratica?

    
posta rockin' 09.07.2018 - 14:16
fonte

0 risposte

Leggi altre domande sui tag