Skip to content
Snippets Groups Projects
Select Git revision
  • renovate/github.com-protonmail-gopenpgp-v3-3.x
  • renovate/github.com-pquerna-otp-1.x
  • renovate/go-1.x
  • renovate/golang.org-x-net-0.x
  • renovate/golang.org-x-crypto-0.x
  • renovate/golang.org-x-sync-0.x
  • renovate/github.com-go-ldap-ldap-v3-3.x
  • renovate/github.com-prometheus-client_golang-1.x
  • renovate/git.autistici.org-id-auth-digest
  • master default protected
  • renovate/github.com-protonmail-gopenpgp-v2-2.x
  • better-validation
12 results

accountserver

  • Clone with SSH
  • Clone with HTTPS
  • ale's avatar
    ale authored
    Also set an initial user password, and random passwords for all its
    resources, on a CreateUser request.
    af4fe0c6
    History

    accountserver

    L'accountserver è il servizio che fa da interfaccia tra il database utenti e gli altri servizi ed applicazioni interne. Disaccoppia la struttura dei dati nel database dal concetto di utente ed account, ed implementa la business logic relativa alle operazioni di alto livello di gestione degli account.

    Le motivazioni per la creazione di questo servizio includono:

    • La constatazione che le applicazioni lato utente (e lato amministratore, come accounts) operano su astrazioni differenti rispetto a quanto implementato a basso livello nello schema LDAP (utenti ed account, anziché oggetti LDAP gerarchici); inoltre, il codice di traduzione è duplicato.

    • I dettagli dell'implementazione di basso livello (LDAP) filtrano ogni volta che scriviamo automazione che opera su utenti o account.

    • La business logic delle operazioni di alto livello, come abilitare / disabilitare un account, o cambiare una password, è spezzata arbitrariamente tra le applicazioni front-end (come il pannello, o accounts) e back-end (il vecchio accountserver), il che ne rende difficile la verifica e la comprensione.

    Si è preferito un servizio RPC anziché una libreria per alcuni importanti motivi:

    • Le informazioni su utenti ed account vanno aggregate da diversi backend (LDAP, redis per dati temporanei, MySQL per noblogs, etc), si vuole evitare una moltiplicazione dei flussi di connettività.

    • Separazione dei privilegi: se tutte le operazioni di scrittura sul database utenti sono effettuate da un unico servizio, le applicazioni front-end possono operare con credenziali di sola lettura (o nessuna).

    • Se tutte le operazioni privilegiate sugli account vengono eseguite da un unico processo, è più facile implementare un buon auditing e verificarne la copertura.

    Modello dati

    Il modello dati offerto da accountserver è piuttosto semplice: l'oggetto di più alto livello è l'utente. Un utente possiede in modo univoco un certo numero di risorse, che possono essere di diversi tipi. Le risorse possono a loro volta avere sotto-risorse, esprimendo una relazione di associazione di qualche tipo (come ad esempio tra siti web e database MySQL).

    Lo schema è definito esplicitamente in types.go.

    Testing

    Per testare questo attrezzo purtroppo serve Java (basta un JRE, il runtime environment). Questo perché non è affatto facile implementare un server LDAP per i test, quindi si è scelto di usarne uno esistente: in particolare un'implementazione Java... su un sistema Debian:

    sudo apt install default-jre-headless

    dovrebbe bastare (oltre a golang-go ovviamente) per poter eseguire i test con successo.