Aggiunta di feature

Autenticazione e autorizzazione

La funzione di autenticazione aggiunge le basi di sicurezza utilizzate dai progetti Lino per proteggere gli API, identificare gli utenti, controllare l'accesso alle operazioni e integrare le stesse autorizzazioni con le app Web Blazor. Si installa con il comando:

lino feature auth add --service <ServiceName> --module <ModuleName>

Il comando può essere eseguito anche in modo interattivo con lino feature auth add. Il ramo canonico è feature auth; CLI espone anche alias come feature security E feature identity.

Nell'attuale architettura Lino, l'autenticazione e l'autorizzazione si basano sulla messaggistica asincrona. Il motivo è operativo: le autorizzazioni del servizio e del modulo sono sincronizzate da eventi di integrazione, quindi il progetto deve avere la messaggistica abilitata prima di aggiungere la sicurezza.

Ciò che chiede il mago

CLI valida il progetto corrente, controlla se la feature non è ancora stata installata, chiede dove creare il modulo di sicurezza e richiede le principali impostazioni del token.

• Servizio: servizio che ospiterà le risorse di sicurezza.
• Modulo: modulo target quando il servizio selezionato è modulare.
• Durata del token di accesso: durata, in minuti, dei token di accesso emessi.
• Aggiorna la durata del token: durata dei token utilizzati per rinnovare le sessioni.
• Tipo di identificatore utente: tipo di dati utilizzati come identificatore dell'utente, come ad esempio int, long O Guid.

Modello di sicurezza generato

Dopo la conferma, Lino aggiorna i metadati del progetto, crea valori di configurazione di sicurezza, genera file di codice sorgente ed esegue i comandi necessari. Il modello generato include le entità di sicurezza centrali:

• User archivia identita e dati del profilo.
• Role e associazioni di ruoli alle regole di accesso al gruppo.
• Permission e relazioni tra ruoli e autorizzazioni per l'autorizzazione granulare.
• UserToken per controllare i token di aggiornamento e il ciclo di vita dei token.

La funzione crea anche le informazioni necessarie per la configurazione della sicurezza, come il segreto per firmare i token e la durata di access token e refresh token. I valori sensibili vengono emessi come comandi per i secrets utente di AppHost, anziché essere scritti direttamente nei file con versione.

Comportamento in fase di esecuzione

L'API utilizza l'autenticazione JWT Bearer. L'utente accede, riceve un access token e un refresh token e inizia a inviare richieste all'API con l'header Authorization: Bearer <token>. Il backend convalida il token, carica il contesto utente e applica le regole di autorizzazione agli endpoint.

Il flusso tipico rimane semplice: accedere tramite endpoint o pagina dedicata, emettere JWT con attestazioni di identità, ruoli e autorizzazioni, inviare il token in ogni richiesta e convalidare la firma e la scadenza tramite il middleware di autenticazione.

Lino utilizza policy e autorizzazioni per implementare l'autorizzazione granulare. Ogni azione può richiedere un'autorizzazione specifica, ad esempio People.Read O People.Create; Le policy possono essere configurate tramite AddAuthorization; e gli endpoint possono essere protetti dichiarando .RequireAuthorization.

Gli endpoint e le pagine generati utilizzano le autorizzazioni in modo coerente. Le operazioni di back-end possono richiedere autorizzazioni, mentre l'interfaccia utente Blazor generata può caricare autorizzazioni, proteggere pagine, nascondere azioni non disponibili ed esporre schermate per utenti, ruoli, autorizzazioni e autorizzazioni quando è presente un'app Web nel progetto.

Quando i Background Jobs sono già abilitati, Lino aggiunge anche lavori relativi ai token utente, come le routine di manutenzione per i token disabilitati o scaduti.

Elaborazione in background e Outbox

L'elaborazione in background gestisce attività che non dovrebbero bloccare il flusso principale di richieste e risposte: pubblicazione di eventi di integrazione, pulizia di vecchi record, rimozione di token scaduti, invio di notifiche, generazione di report, sincronizzazione con sistemi esterni o esecuzione di attività pianificate. Lino aggiunge questa feature tramite la funzione di lavoro in background:

lino feature background-job add --service <ServiceName>

Il comando può anche essere eseguito come lino feature background-job add e completato in modo interattivo. CLI espone gli alias come job-scheduler E worker.

Questa feature richiede la messaggistica abilitata nel progetto, poiché la sua responsabilità principale è pubblicare in modo sicuro i messaggi registrati dallo standard transazionale Outbox.

Ciò che chiede il mago

• Servizio: servizio in cui verrà installata l'infrastruttura dei Background Jobs.
• Libreria di Background Jobs: implementazione utilizzata per l'esecuzione e la pianificazione dei lavori. L'infrastruttura attualmente generata utilizza Hangfire.
• Outbox Elaborazione: definisce se il servizio registrerà gli eventi che dovranno essere elaborati dallo scheduler.
• CronOutboxMessaggi: intervallo o espressione di pianificazione utilizzata per verificare la presenza di nuovi messaggi Outbox.
• Dimensione lotto: numero di record Outbox recuperati ed elaborati per ciclo, controllando carico, parallelismo e consumo di risorse.

Hangfire Infrastruttura

Lino genera l'infrastruttura necessaria per registrare Hangfire, configurarne la persistenza, esporre la dashboard e pianificare i lavori utilizzati dal servizio. La configurazione generata include le informazioni necessarie per pianificare i job, elaborare i messaggi Outbox e proteggere accesso al dashboard dello scheduler.

Nelle soluzioni generate, lo schema e le tabelle Hangfire fanno parte della configurazione del database dell'applicazione. Il dashboard ti aiuta a ispezionare i lavori completati, non riusciti, pianificati e ricorrenti durante lo sviluppo e il funzionamento.

I vantaggi pratici includono l'esecuzione affidabile di attività asincrone, dashboard di monitoraggio integrato, supporto per lavori ricorrenti o pianificati e persistenza dei lavori nel database.

Elaborazione con transazionale Outbox

Per garantire la coerenza nelle integrazioni asincrone, Lino utilizza il modello Transazionale Outbox. Un caso d'uso aziendale rende persistenti le modifiche al dominio e registra un evento di integrazione nella tabella Outbox all'interno della stessa transazione. Il processo in background legge quindi la tabella Outbox e pubblica l'evento tramite il bus di messaggi configurato, come RabbitMQ con MassTransit quando queste opzioni sono state selezionate per il progetto.

1. Un comando modifica lo stato del dominio e salva questa modifica in una transazione.
2. Un gestore registra un evento di integrazione in Outbox, ad esempio un evento relativo alla creazione di un ordine.
3. Il lavoro Hangfire blocca un batch di messaggi non elaborati e contrassegna questi messaggi come in elaborazione.
4. Ogni messaggio viene deserializzato e pubblicato dal bus degli eventi.
5. I messaggi riusciti vengono contrassegnati come elaborati; I messaggi non riusciti conservano le informazioni sull'errore per un'analisi successiva o una strategia di nuovo tentativo.

Il risultato è atomicità tra il database e gli eventi registrati, affidabilità in modo che gli eventi non vadano persi in caso di guasto e scalabilità in modo che più consumatori elaborino i messaggi pubblicati.

Il lavoro generato include anche routine per rimuovere i vecchi messaggi Outbox che sono già stati elaborati con successo e rilasciare i messaggi bloccati nell'elaborazione, riducendo il rischio di blocchi permanenti dopo errori dell'applicazione.

Quando è installata l'autenticazione, la feature di lavoro in background può anche ospitare lavori di manutenzione dei token, mantenendo puliti i dati di sicurezza nel tempo.

Con queste feature aggiuntive, Lino offre sicurezza solida, controllo granulare degli accessi ed elaborazione asincrona affidabile per i requisiti critici delle moderne applicazioni di produzione.

Multi-tenancy

La multi-tenancy è la feature utilizzata quando la stessa applicazione deve servire più clienti, organizzazioni o ambienti mantenendo dati, autorizzazioni e configurazioni isolate per ciascun tenant. In Lino, il supporto del tenant viene aggiunto con:

lino feature tenant add --service <ServiceName> --module <ModuleName>

Il comando può essere eseguito anche in modo interattivo con lino feature tenant add. Il ramo CLI espone anche alias come tenancy.

Prerequisiti

Il supporto del tenant dipende da due feature dell'architettura:

• Autenticazione e autorizzazione, poiché l'accesso degli utenti, i ruoli, le autorizzazioni e i token devono essere consapevoli del tenant.
• Messaggistica, poiché le informazioni sul tenant e sull'utente possono essere propagate ad altri moduli tramite eventi di integrazione.

Se mancano questi prerequisiti il ​​comando viene rifiutato. La feature può anche essere installata solo una volta per progetto.

Cosa viene generato

Lino crea il modello di tenancy, la configurazione, gli eventi, l'integrazione API e le risorse frontend necessarie per gestire i tenant in modo coerente.

• Tenant archivia identita del tenant, il nome, lo slug, lo stato, la modalita di isolamento e il riferimento alla stringa di connessione.
• TenantBranding memorizza i dati di branding per comportamenti visivi specifici per tenant.
• TenantDomain associa host o domini ai tenant.
• TenantStatus E IsolationMode definire il ciclo di vita del tenant e le opzioni di isolamento dei dati.
• La configurazione generata supporta la risoluzione dei tenant e isolamento dei dati del progetto.

Sicurezza consapevole del tenant

La tenancy modifica il modo in cui vengono interpretate l'autenticazione e l'autorizzazione. Un token e un'autorizzazione validi vengono valutati nel contesto del tenant corrente; un utente con accesso in un tenant non riceve automaticamente l'accesso a un altro tenant. Pertanto, il supporto del tenant aggiorna i flussi di autenticazione, aggiorna il comportamento dei token, le autorizzazioni e i riferimenti generati per l'interfaccia utente.

Nelle applicazioni Blazor generate, è possibile aggiungere schermate tenant-aware per la gestione dei tenant e dei flussi di autorizzazione. Sul back-end, gli endpoint generati possono risolvere il contesto del tenant dal comportamento configurato di host, slug o route e quindi applicare l'identificatore del tenant nelle decisioni relative ai dati e alle autorizzazioni.

Isolamento e propagazione dei dati

Lino supporta la modellazione di domini tenant-aware consentendo alle entità di dichiarare la proprietà in base al tenant. Negli scenari SaaS, ciò consente alle tabelle aziendali di archiviare dati specifici del tenant mentre i moduli condivisi continuano a ricevere le informazioni sul tenant e sull'utente di cui hanno bisogno.

L'architettura generata utilizza gli eventi e il modello Outbox per propagare i dati utente o tenant selezionati tra i moduli senza accoppiare tutti i moduli direttamente alle tabelle di identità o tenancy originali. Ciò mantiene chiari i confini del modulo, mentre schermate, API, autorizzazioni e query continuano a funzionare con il contesto del tenant.

Dopo aver aggiunto la tenancy, crea e applica le migrazioni per il servizio interessato, esamina i secrets generati e le chiavi API, esegui AppHost ed esegui la convalida con almeno due tenant per garantire che dati, utenti, ruoli, autorizzazioni e record aziendali rimangano isolati.

• Convalidare l'isolamento: creare test tentando di accedere ai dati da un altro tenant.
• Autorizzazioni di revisione: un utente può avere ruoli diversi in tenant diversi.
• Evitare di fidarsi del cliente: il tenant informato per percorso, host, slug o intestazione deve essere compatibile con l'utente autenticato.