Ajout de features

Authentification et autorisation

La fonction d'authentification ajoute la base de sécurité utilisée par les projets Lino pour protéger les API, identifier les utilisateurs, contrôler l'accès aux opérations et intégrer les mêmes autorisations avec les applications Web Blazor. Il s'installe avec la commande:

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

La commande peut également être exécutée de manière interactive avec lino feature auth add. La branche canonique est feature auth; CLI expose également des alias comme feature security et feature identity.

Dans l'architecture Lino actuelle, l'authentification et l'autorisation reposent sur la messagerie asynchrone. La raison est opérationnelle : les autorisations des services et des modules sont synchronisées par les événements d'intégration, le projet doit donc activer la messagerie avant d'ajouter la sécurité.

Ce que demande le sorcier

CLI valide le projet en cours, vérifie si la feature n'a pas encore été installée, demande où le module de sécurité doit être créé et demande les principaux paramètres du token.

• Service: service qui hébergera les ressources de sécurité.
• Module: module cible lorsque le service sélectionné est modulaire.
• Durée de vie du jeton d'accès: durée de vie, en minutes, des jetons d'accès émis.
• Actualiser la durée de vie du jeton: durée de vie des tokens utilisés pour renouveler les sessions.
• Type d'identifiant utilisateur: type de données utilisées comme identifiant d'utilisateur, telles que int, long ou Guid.

Modèle de sécurité généré

Après confirmation, Lino met à jour les métadonnées du projet, crée les valeurs de configuration de sécurité, génère les fichiers de code source et exécute les commandes nécessaires. Le modèle généré inclut les entités centrales de sécurité :

• User stocke les identites et les donnees de profil.
• Role et des associations de rôles pour regrouper les règles d'accès.
• Permission et les relations entre les rôles et les autorisations pour une autorisation granulaire.
• UserToken pour contrôler les jetons d'actualisation et le cycle de vie des jetons.

La feature cree egalement les informations necessaires a la configuration de securite, comme le secret de signature des tokens et les durees de vie de access token et de refresh token. Les valeurs sensibles sont émises sous forme de commandes vers les secrets utilisateur AppHost, plutôt que d'être écrites directement dans des fichiers versionnés.

Comportement d'exécution

L'API utilise l'authentification JWT Bearer. L'utilisateur se connecte, reçoit un access token et un refresh token, puis commence à envoyer des requêtes à l'API avec l'en-tête Authorization: Bearer <token>. Le backend valide le jeton, charge le contexte utilisateur et applique les règles d'autorisation aux endpoints.

Le flux typique reste simple : connexion via un point de terminaison ou une page dédiée, émission de JWT avec des revendications d'identité, des rôles et des autorisations, envoi du jeton dans chaque demande et validation de la signature et de l'expiration via le middleware d'authentification.

Lino utilise des stratégies et des autorisations pour implémenter une autorisation granulaire. Chaque action peut nécessiter une autorisation spécifique, telle que People.Read ou People.Create; Les politiques peuvent être configurées via AddAuthorization; et les points finaux peuvent être protégés en déclarant .RequireAuthorization.

Les endpoints et les pages générés utilisent les autorisations de manière cohérente. Les opérations backend peuvent nécessiter des autorisations, tandis que l'interface utilisateur Blazor générée peut charger des autorisations, protéger des pages, masquer les actions indisponibles et exposer des écrans pour les utilisateurs, les rôles, les autorisations et les autorisations lorsqu'il existe une application Web dans le projet.

Lorsque les tâches en arrière-plan sont déjà activées, Lino ajoute également des tâches liées aux jetons utilisateur, telles que des routines de maintenance pour les jetons désactivés ou expirés.

Traitement en arrière-plan et Outbox

Le traitement en arrière-plan gère les tâches qui ne doivent pas bloquer le flux principal de requêtes et de réponses : publication d'événements d'intégration, nettoyage d'anciens enregistrements, suppression de jetons expirés, envoi de notifications, génération de rapports, synchronisation avec des systèmes externes ou exécution de tâches planifiées. Lino ajoute cette feature via la feature de travail en arrière-plan :

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

La commande peut également être exécutée comme lino feature background-job add et complété de manière interactive. CLI expose les alias comme job-scheduler et worker.

Cette feature nécessite l'activation de la messagerie dans le projet, car sa principale responsabilité est de publier en toute sécurité les messages enregistrés par la norme Transactionnelle Outbox.

Ce que demande le sorcier

• Service: service dans lequel l'infrastructure des jobs en arrière-plan sera installée.
• Bibliothèque de tâches en arrière-plan: implémentation utilisée pour exécuter et planifier les tâches. L'infrastructure actuellement générée utilise Hangfire.
• Traitement Outbox: définit si le service enregistrera les événements à traiter par le planificateur.
• Planification Outbox: expression de plage ou de planification utilisée pour vérifier les nouveaux messages Outbox.
• Taille du lot: nombre d'enregistrements Outbox récupérés et traités par cycle, contrôlant la charge, le parallélisme et la consommation des ressources.

Infrastructure Hangfire

Lino génère l'infrastructure nécessaire pour enregistrer Hangfire, configurer sa persistance, exposer le tableau de bord et planifier les tâches utilisées par le service. La configuration generee inclut les informations necessaires pour planifier les jobs, traiter les messages Outbox et proteger acces au tableau de bord du planificateur.

Dans les solutions générées, le schéma et les tables Hangfire font partie de la configuration de la base de données de l'application. Le tableau de bord vous aide à inspecter les tâches terminées, échouées, planifiées et récurrentes pendant le développement et l'exploitation.

Les avantages pratiques incluent une exécution fiable de tâches asynchrones, un tableau de bord de surveillance intégré, la prise en charge des tâches récurrentes ou planifiées et la persistance des tâches dans la base de données.

Traitement avec Outbox transactionnel

Pour garantir la cohérence des intégrations asynchrones, Lino utilise le modèle Transactional Outbox. Un cas d'utilisation métier conserve les modifications de domaine et enregistre un événement d'intégration dans la table Outbox au sein de la même transaction. Le travail en arrière-plan lit ensuite la table Outbox et publie l'événement via le bus de messages configuré, tel que RabbitMQ avec MassTransit lorsque ces options ont été sélectionnées pour le projet.

1. Une commande modifie l'état du domaine et enregistre ce changement dans une transaction.
2. Un gestionnaire enregistre un événement d'intégration dans Outbox, par exemple un événement lié à la création d'une commande.
3. Le travail Hangfire bloque un lot de messages non traités et marque ces messages comme étant en cours de traitement.
4. Chaque message est désérialisé et publié par le bus d'événements.
5. Les messages réussis sont marqués comme traités ; Les messages ayant échoué conservent les informations sur les erreurs pour une analyse ultérieure ou une stratégie de nouvelle tentative.

Le résultat est l'atomicité entre la base de données et les événements enregistrés, la fiabilité afin que les événements ne soient pas perdus en cas de panne et l'évolutivité afin que plusieurs consommateurs traitent les messages publiés.

Le travail généré comprend également des routines pour supprimer les anciens messages Outbox qui ont déjà été traités avec succès et libérer les messages bloqués en cours de traitement, réduisant ainsi le risque de verrouillages permanents après des échecs d'application.

Lorsque l'authentification est installée, la feature de tâche en arrière-plan peut également héberger des tâches de maintenance de jetons, gardant ainsi les données de sécurité propres au fil du temps.

Grâce à ces features supplémentaires, Lino offre une sécurité robuste, un contrôle d'accès granulaire et un traitement asynchrone fiable pour les exigences critiques des applications de production modernes.

Multitenancy

La multi-tenancy est la feature utilisée lorsque la même application doit servir plusieurs clients, organisations ou environnements tout en conservant des données, des autorisations et des configurations isolées pour chaque tenant. Dans Lino, la prise en charge des tenants est ajoutée avec :

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

La commande peut également être exécutée de manière interactive avec lino feature tenant add. La branche CLI expose également des alias comme tenancy.

Conditions préalables

La prise en charge des tenants dépend de deux capacités architecturales :

• Authentification et autorisation, car l'accès des utilisateurs, les rôles, les autorisations et les jetons doivent tenir compte des tenants.
• Messagerie, car les informations sur le tenant et l'utilisateur peuvent être propagées à d'autres modules par des événements d'intégration.

Si ces prérequis sont manquants, la commande est rejetée. La feature ne peut également être installée qu’une seule fois par projet.

Ce qui est généré

Lino crée le modèle de tenancy, la configuration, les événements, l'intégration API et les ressources frontales nécessaires pour gérer les tenants de manière cohérente.

• Tenant stocke identite du tenant, son nom, son slug, son statut, son mode isolation et sa reference de chaine de connexion.
• TenantBranding stocke les données de marque pour un comportement visuel spécifique par tenant.
• TenantDomain mappe les hôtes ou les domaines aux tenants.
• TenantStatus et IsolationMode définir le cycle de vie des tenants et les options d’isolation des données.
• La configuration generee prend en charge la resolution des tenants et isolation des donnees du projet.

Sécurité adaptée aux tenants

Tenancy modifie la façon dont l'authentification et l'autorisation sont interprétées. Un jeton et une autorisation valides sont évalués dans le contexte du tenant actuel ; un utilisateur ayant accès à un tenant ne reçoit pas automatiquement l'accès à un autre tenant. Par conséquent, la prise en charge des tenants met à jour les flux d’authentification, le comportement du jeton d’actualisation, les autorisations et les références générées pour l’interface utilisateur.

Dans les applications Blazor générées, des écrans tenant compte des tenants peuvent être ajoutés pour gérer les tenants et les flux d'autorisation. Sur le backend, les endpoints générés peuvent résoudre le contexte du tenant à partir du comportement configuré de l'hôte, du slug ou de la route, puis appliquer l'identifiant du tenant dans les décisions de données et d'autorisation.

Isolation et propagation des données

Lino prend en charge la modélisation de domaine tenant compte des tenants en permettant aux entités de déclarer la propriété par tenant. Dans les scénarios SaaS, cela permet aux tables métier de stocker des données spécifiques au tenant tandis que les modules partagés continuent de recevoir les informations sur le tenant et l'utilisateur dont ils ont besoin.

L'architecture générée utilise des événements et le modèle Outbox pour propager les données de tenant ou d'utilisateur sélectionnées entre les modules sans coupler tous les modules directement aux tables d'identité ou de tenancy d'origine. Cela maintient les limites des modules claires, tandis que les écrans, les API, les autorisations et les requêtes continuent de fonctionner avec le contexte du tenant.

Après avoir ajouté la tenancy, créez et appliquez les migrations pour le service concerné, examinez les secrets générés et les clés API, exécutez AppHost et validez avec au moins deux tenants pour garantir que les données, les utilisateurs, les rôles, les autorisations et les enregistrements commerciaux restent isolés.

• Valider l'isolement : créer des tests en essayant d'accéder aux données d'un autre tenant.
• Examiner les autorisations : un utilisateur peut avoir différents rôles dans différents tenants.
• Évitez de faire confiance au client : le tenant informé par route, hôte, slug ou en-tête doit être compatible avec l'utilisateur authentifié.