Fichier de Configuration du Rest Frontage
- Type non défini
Ce document décrit les paramètres propres à RestFrontage et aux bibliothèques GraphicStream qu’il initialise.
Les rubriques ASP.NET Core standard, comme Logging, AllowedHosts ou le choix de l’environnement d’hébergement, ne sont pas détaillées. Elles sont l'appanage du système sous jacent à ASP.Net et à IIS.
Une clé présente dans appsettings.json n’a pas nécessairement d’effet. Les paramètres inactifs ou ignorés sont signalés explicitement dans ce document.
1. Vue d’ensemble
| Section | Statut | Rôle |
|---|---|---|
Database |
Requise | Choisit SQL Server LocalDB, SQLite ou SQL Server distant et nomme les bases métier et sécurité locales. |
ConnectionStrings |
Requise en mode SQL Server distant | Configure les bases métier, sécurité, serveur et licences. |
LogsSettings |
Requise | Configure le logger GraphicStream et la destination des journaux. |
IOSettings |
Requise en pratique | Configure le stockage des médias et fichiers. |
Application |
Requise | Configure l’identité du serveur, les jetons, les mots de passe vides, le préchauffage et la boucle de tâches. |
Application:OpenAI |
Conditionnelle | Configure les fonctions IA utilisant Azure OpenAI Assistants. |
Environment |
Optionnelle | Affiche un bandeau permettant d’identifier visuellement l’environnement. |
SecurityDomainSynchronization |
Optionnelle | Règle la synchronisation du domaine de sécurité entre instances. |
Recovery |
Recommandée | Protège la console de récupération indépendante de la base de sécurité. |
ApiKey |
Conditionnelle | Déclare des clés d’API associées à des utilisateurs Immersive. |
Saml |
Conditionnelle | Configure l’authentification SAML avec la FID. |
OpenID |
Conditionnelle | Configure la validation de jetons OpenID auprès de la FID. |
Session |
Optionnelle | Active la session serveur uniquement lorsque la section contient au moins un paramètre. Une section absente ou vide conserve le fonctionnement sans session. |
IPX |
Inactive | La section IPX:Export du fichier fourni n’est lue par aucun composant. |
2. Sélection du mode de base de données
RestFrontage applique cette priorité :
Database:EnableLocalDB = truesélectionne SQL Server LocalDB ;- sinon,
Database:EnableSqlite = truesélectionne SQLite ; - sinon, RestFrontage utilise les chaînes SQL Server de
ConnectionStrings.
Si les deux indicateurs valent true, LocalDB gagne et le paramètre SQLite est ignoré.
2.1 SQL Server distant ou SQL Server Express
Configuration minimale recommandée pour un déploiement complet :
{
"Database": {
"EnableLocalDB": false,
"EnableSqlite": false
},
"ConnectionStrings": {
"ImmersiveModelContainer": "<chaine SQL de la base metier>",
"SecurityModelContainer": "<chaine SQL de la base de securite>",
"ServerDatabaseContext": "<chaine SQL des donnees serveur>",
"LicenseModelContainer": "<chaine SQL des licences>"
}
}
| Clé | Obligatoire | Utilisation et repli |
|---|---|---|
ImmersiveModelContainer |
Oui | Données métier Immersive. Sert aussi de repli à ServerDatabaseContext. |
SecurityModelContainer |
Oui | Utilisateurs, groupes, droits et domaine de sécurité. Sert aussi de repli à LicenseModelContainer. |
ServerDatabaseContext |
Non | Tâches serveur et données IA internes. L’historique et les sessions de travail IPX utilisent également cette connexion. Sans valeur ou si non spécifiée, la base métier est utilisée. |
LicenseModelContainer |
Non | Licences installées. Sans valeur ou si non spécifiée, la base de sécurité est utilisée. |
En mode SQL Server, les accès aux bases métier, sécurité, serveur, licences et historique IPX activent cinq nouvelles tentatives au maximum sur les erreurs SQL transitoires, avec un délai maximal de dix secondes entre les tentatives.
La base des journaux ne se configure pas dans ConnectionStrings. Elle utilise exclusivement LogsSettings:ConnectionString.
2.2 SQLite
{
"Database": {
"EnableLocalDB": false,
"EnableSqlite": true,
"ImmersiveSqlite": "Immersive.sqlite",
"ImmersiveSecuritySqlite": "ImmersiveSecurity.sqlite"
},
"LogsSettings": {
"ConnectionString": "ImmersiveLogs.sqlite"
}
}
| Clé | Rôle |
|---|---|
ImmersiveSqlite |
Base métier et stockage de l’historique IPX. |
ImmersiveSecuritySqlite |
Base de sécurité. |
LogsSettings:ConnectionString contient ici le nom ou le chemin relatif du fichier SQLite des journaux. Le logger et le contexte de consultation utilisent tous les deux ce même fichier.
Les chemins SQLite sont résolus relativement au dossier contenant l’exécutable RestFrontage et les fichiers doivent déjà exister. Le code actuel ne crée pas les fichiers SQLite manquants.
En mode SQLite, les contextes ServerDatabaseContext et LicenseSecurityModel ne sont pas enregistrés. Les fonctions qui en dépendent ne disposent donc pas de leur stockage complet.
2.3 SQL Server LocalDB
{
"Database": {
"EnableLocalDB": true,
"EnableSqlite": false,
"ImmersiveDatabaseName": "Immersive",
"ImmersiveSecurityDatabaseName": "ImmersiveSecurity",
"ImmersiveBacPacName": "Immersive.bacpac",
"ImmersiveSecurityBacPacName": "ImmersiveSecurity.bacpac",
"ImmersiveLogBacPacName": "ImmersiveLogs.bacpac"
},
"LogsSettings": {
"ConnectionString": "ImmersiveLogs"
}
}
| Clé | Obligatoire | Rôle |
|---|---|---|
ImmersiveDatabaseName |
Oui | Nom du fichier <nom>.mdf et de la base métier. |
ImmersiveSecurityDatabaseName |
Oui | Nom du fichier et de la base de sécurité. |
ImmersiveBacPacName |
Non | BACPAC initial de la base métier. |
ImmersiveSecurityBacPacName |
Non | BACPAC initial de la base de sécurité. |
ImmersiveLogBacPacName |
Non | BACPAC initial de la base des journaux dont le nom est donné par LogsSettings:ConnectionString. |
LogsSettings:ConnectionString contient ici le nom logique de la base LocalDB des journaux, sans extension .mdf et non une chaîne SQL complète. Dans l’exemple, RestFrontage ouvre ou crée ImmersiveLogs.mdf, puis le logger et le contexte de consultation réutilisent la chaîne LocalDB réellement obtenue.
Les fichiers MDF sont placés dans le sous-dossier Data situé à côté des assemblages. Lors de la création d’une base, un BACPAC renseigné est recherché sous Assets/Bacpac.
Ce mode nécessite SQL Server LocalDB sur la machine. Comme en mode SQLite, le code actuel n’enregistre pas ServerDatabaseContext ni LicenseSecurityModel.
2.4 Une seule destination pour les journaux
La destination des journaux est toujours définie par LogsSettings:ConnectionString. RestFrontage interprète automatiquement sa valeur selon le mode choisi sous Database :
| Mode | Valeur attendue dans LogsSettings:ConnectionString |
Résolution effectuée |
|---|---|---|
| SQL Server distant | Chaîne de connexion SQL Server complète. | La chaîne est utilisée telle quelle. |
| SQL Server LocalDB | Nom logique de la base, par exemple ImmersiveLogs. |
RestFrontage ouvre ou crée le fichier <nom>.mdf, puis construit la chaîne LocalDB. |
| SQLite | Nom ou chemin relatif du fichier, par exemple ImmersiveLogs.sqlite. |
RestFrontage vérifie le fichier à côté de l’exécutable et construit la connexion SQLite. |
Cette résolution est commune aux deux usages : le logger par lots qui écrit les messages et le contexte LogsContext qui les consulte. Ils ne peuvent donc plus pointer involontairement vers deux bases différentes.
En LocalDB, ne renseignez pas une chaîne SQL complète dans LogsSettings:ConnectionString, mais uniquement le nom logique de la base. En SQLite, le fichier doit déjà exister.
3. Journaux GraphicStream - LogsSettings
Le logger GraphicStream écrit les journaux en arrière-plan afin de ne pas ouvrir une connexion pour chaque message. Lorsqu’un message est produit, il est placé dans une file d’attente en mémoire. À intervalles réguliers, le logger prélève un groupe de messages dans cette file et l’insère dans la base sélectionnée.
Les paramètres de cette section définissent donc quatre éléments : la destination, l’identification de l’outil producteur, la capacité de la file d’attente et la manière dont les messages sont regroupés puis conservés.
{
"LogsSettings": {
"ProviderIdentifier": 10,
"IncludeScopes": true,
"IsEnabled": true,
"ContainerName": "Log",
"ConnectionString": "<chaine SQL de la base des journaux>",
"FlushPeriod": "00:00:01",
"BackgroundQueueSize": 1000,
"BatchSize": null,
"TableSizeLimit": 10240
}
}
| Clé | Défaut | Effet réel et conseils de paramétrage |
|---|---|---|
ConnectionString |
aucun | Destination unique du logger et du contexte de consultation. En SQL Server distant, renseigner une chaîne SQL complète ; en LocalDB, le nom logique de la base ; en SQLite, le nom ou chemin relatif du fichier. La valeur est indépendante de la section ConnectionStrings. |
ContainerName |
Log |
Nom de la table recevant les journaux. La valeur recommandée est Log, qui correspond au schéma fourni par GraphicStream. |
ProviderIdentifier |
0 |
Permet de différencier les différents outils qui injectent dans Log, afin de mutualiser une même base de journaux entre plusieurs outils GraphicStream, par exemple plusieurs RestFrontage et/ou Hub. |
IncludeScopes |
true |
Autorise la lecture des informations structurées placées dans les scopes de journalisation. Le logger reconnaît notamment Channel, qui classe le message dans un canal, et Data, qui ajoute des données complémentaires. Sans canal fourni, le message est rangé dans le canal Generic. |
IsEnabled |
true |
Active le provider de journaux GraphicStream. À false, sa file de traitement est arrêtée et les nouveaux messages ne sont pas enregistrés par ce provider. Ce réglage ne désactive pas nécessairement les autres destinations de logs éventuellement configurées. |
FlushPeriod |
00:00:01 |
Durée d’attente entre deux cycles d’écriture. Avec une seconde, les messages en attente sont envoyés vers la base environ chaque seconde. Une valeur plus courte réduit le délai d’apparition en base mais augmente la fréquence des accès ; une valeur plus longue regroupe davantage les écritures mais retarde leur visibilité. La durée doit être strictement positive. |
BackgroundQueueSize |
1000 |
Nombre maximal de messages pouvant attendre en mémoire avant leur traitement. Lorsque la file bornée est pleine, le producteur attend qu’une place se libère : une valeur trop faible peut donc ralentir les requêtes lors d’un afflux de logs. null crée une file sans limite, au prix d’une consommation mémoire potentiellement plus importante. Utiliser une valeur strictement positive ; 0 est accepté par la classe d’options mais ne permet pas de construire la file à l’exécution. |
BatchSize |
null |
Nombre maximal de messages retirés de la file et insérés au cours d’un cycle. null traite tous les messages disponibles. Une valeur positive limite la taille de chaque lot ; si la file contient davantage de messages, le reste attend les cycles suivants. Une valeur trop faible peut créer du retard lorsque beaucoup de journaux sont produits. |
TableSizeLimit |
10240 |
Nombre maximal de lignes conservées. Après l’écriture d’un lot, le logger supprime les entrées les plus anciennes, selon leur date, pour revenir sous cette limite. null désactive cette purge automatique. Une valeur renseignée doit être strictement positive. |
Exemple de fonctionnement avec les valeurs ci-dessus : jusqu’à 1 000 messages peuvent attendre dans la file ; environ toutes les secondes, tous les messages disponibles sont écrits en lot puisque BatchSize vaut null ; après l’écriture, les plus anciens journaux sont supprimés si la table dépasse 10 240 lignes.
Avec le provider SQL Server, le mécanisme actuel de purge de TableSizeLimit cible explicitement la table Log. Si ContainerName porte un autre nom, les nouveaux messages sont envoyés vers cette autre table mais la purge continue de viser Log. Le provider SQLite purge bien la table indiquée. Il reste recommandé de conserver ContainerName à Log.
Storage ne doit pas être choisi manuellement pour RestFrontage. L’application le force à SQL pour SQL Server distant et LocalDB, ou à SQLite lorsque Database:EnableSqlite est activé. Une éventuelle valeur Storage présente dans le JSON est donc remplacée par ce choix calculé.
FileSizeLimit, RetainedFileCountLimit, FileName et Extension existent dans la classe d’options, mais ne sont pas utilisés par les providers SQL Server et SQLite sélectionnés par RestFrontage.
Les niveaux sous Logging et Logging:GraphicStreamLogs:LogLevel relèvent du filtrage standard des logs et ne sont pas détaillés ici.
4. Stockage des fichiers - IOSettings
{
"IOSettings": {
"Storage": "AzureBlob",
"ConnectionString": "<secret ou chemin selon le mode>",
"ContainerName": "immersivecontent"
}
}
Storage |
ConnectionString |
ContainerName |
|---|---|---|
AzureBlob |
Chaîne de connexion du compte Azure Storage. | Nom du conteneur Blob. |
FileSystem |
Dossier racine du stockage. | Sous-dossier ajouté à la racine. |
HostEnvironment |
Ignorée. | Sous-dossier du répertoire racine de RestFrontage. |
SQL |
Chaîne de connexion SQL Server. | Nom de la table contenant notamment le chemin et le contenu binaire. |
Une modification nécessite un redémarrage pour être appliquée de façon cohérente.
Pour HostEnvironment, toutes les opérations utilisent la même racine : ContentRootPath, c’est-à-dire le répertoire racine de RestFrontage. Le test d’existence, la lecture, l’écriture, la liste et la suppression ciblent donc tous <ContentRootPath>/<ContainerName>/<chemin> ; ConnectionString est ignorée dans ce mode.
5. Paramètres généraux RestFrontage - Application
{
"Application": {
"Name": "RestFrontage PROD",
"AllowBlankPassword": false,
"PreWarmOrganizations": [ "Organisation A" ],
"TokenLifetime": "08:00:00",
"JWTSecurityKey": "<secret aleatoire d'au moins 32 octets>",
"TaskManagerLoopIdleTime": 60
}
}
| Clé | Défaut | Effet réel |
|---|---|---|
Name |
null |
Nom retourné par l’API système ; repli visible : ImmersiveRest Server. |
AllowBlankPassword |
false |
Autorise l’authentification avec un mot de passe vide et influence l’audit d’initialisation. À laisser à false en production. |
PreWarmOrganizations |
null |
Noms des organisations dont les caches sont préchargés au démarrage. Un tableau vide conserve le chargement à la demande. |
TokenLifetime |
08:00:00 |
Durée des JWT émis par RestFrontage. |
JWTSecurityKey |
aucun fiable | Secret HMAC servant à signer et valider les JWT. Il doit dépasser 256 bits, rester identique entre instances et ne jamais être commité. Le changer invalide les jetons existants. |
TaskManagerLoopIdleTime |
60 |
Pause, en secondes, entre deux passages de la boucle des tâches serveur. Utiliser une valeur strictement positive. |
La section Application doit exister : l’application liée est ensuite demandée comme service obligatoire lors de l’initialisation.
En production, AllowBlankPassword doit rester à false et JWTSecurityKey doit être un secret aléatoire d’au moins 32 octets, identique sur toutes les instances.
6. Azure OpenAI - Application:OpenAI
{
"Application": {
"OpenAI": {
"Endpoint": "https://<ressource>.openai.azure.com",
"ApiKey": "<secret>",
"AssistantName": "asst_<identifiant>",
"APIVersion": "2024-05-01-preview"
}
}
}
| Clé | Obligatoire pour l’IA | Rôle |
|---|---|---|
Endpoint |
Oui | URL de la ressource Azure OpenAI. Le slash final est retiré par le service. |
ApiKey |
Oui | Valeur envoyée dans l’en-tête api-key. |
AssistantName |
Oui | Malgré son nom, cette valeur doit être l’identifiant technique de l’assistant, par exemple asst_.... |
APIVersion |
Non | Version de l’API Azure OpenAI ; défaut 2024-05-01-preview. |
L’absence de cette sous-section n’empêche pas le démarrage ; l’erreur est levée lors du premier appel à une fonction IA nécessitant ces valeurs.
7. Identification visuelle - Environment
{
"Environment": {
"Name": "PROD",
"BackgroundColor": "#B00020",
"ForegroundColor": "#FFFFFF",
"Size": 6
}
}
| Clé | Défaut | Rôle |
|---|---|---|
Name |
vide | Texte affiché sur l’accueil et dans le fil d’Ariane. Sans nom, le badge d’accueil est masqué. |
BackgroundColor |
#333 |
Couleur CSS de fond du repère d’environnement. |
ForegroundColor |
white |
Couleur CSS du texte. |
Size |
7 |
Suffixe de la classe Bootstrap fs-{Size} dans le fil d’Ariane. Utiliser une valeur Bootstrap valide de 1 à 6. |
Cette section décrit un repère visuel RestFrontage ; elle est distincte du nom d’environnement d’hébergement ASP.NET Core.
8. Synchronisation de la sécurité - SecurityDomainSynchronization
{
"SecurityDomainSynchronization": {
"VersionCheckInterval": "00:00:01"
}
}
VersionCheckInterval est l’intervalle entre deux lectures de la version distribuée du domaine de sécurité. Lorsqu’une autre instance publie une nouvelle version, RestFrontage recharge son domaine local.
La valeur par défaut est une seconde. Une durée nulle ou négative est remplacée par une seconde.
Toutes les instances partageant les mêmes bases doivent utiliser un intervalle cohérent. Une valeur très courte réduit le délai de propagation mais augmente les accès au cache distribué.
9. Console de récupération - Recovery
{
"Recovery": {
"AccessKey": "<secret long et aleatoire>"
}
}
AccessKey protège la page /Setup/Tools, conçue pour rester accessible même lorsque la base de sécurité est défaillante. Sans clé, la console ne peut pas être déverrouillée. Après validation, l’accès est conservé dans un cookie signé pendant 30 minutes.
La variable d’environnement dédiée IMMERSIVE_RECOVERY_KEY est prioritaire sur Recovery:AccessKey et doit être privilégiée en production.
Cas des Surcharges de récupération
Une surcharge de récupération est une valeur de configuration de secours qui remplace temporairement la valeur normale portant le même nom. Elle sert à réparer un serveur dont une connexion, les journaux ou le stockage sont mal configurés, sans modifier directement le fichier appsettings.json d’origine.
La console /Setup/Tools enregistre ces valeurs dans le fichier optionnel appsettings.Recovery.json, placé dans le répertoire racine de RestFrontage. Par exemple, si ce fichier contient une nouvelle valeur pour ConnectionStrings:ImmersiveModelContainer, cette valeur remplace celle de appsettings.json au prochain démarrage. Les autres clés qui ne figurent pas dans le fichier de récupération continuent à provenir de la configuration normale.
La console peut créer ou compléter les sections suivantes :
- les quatre chaînes reconnues de
ConnectionStrings; LogsSettings;IOSettings.
Le fichier de récupération fonctionne donc comme une couche partielle superposée à la configuration existante :
appsettings.jsonet les autres fichiers de configuration habituels fournissent les valeurs normales ;appsettings.Recovery.jsonremplace uniquement les clés qu’il contient ;- les variables d’environnement et les arguments de lancement restent prioritaires sur les deux fichiers.
Exemple :
{
"ConnectionStrings": {
"ImmersiveModelContainer": "<chaine SQL de remplacement>"
},
"IOSettings": {
"Storage": "FileSystem",
"ConnectionString": "D:\\ImmersiveData",
"ContainerName": "Content"
}
}
Dans cet exemple, seules la base métier et la section IOSettings sont surchargées. La base de sécurité, les licences, les journaux et tous les autres paramètres conservent leurs valeurs normales.
Après un enregistrement, les boutons de diagnostic de la console peuvent tester les nouvelles valeurs avec des objets temporaires. En revanche, les services réellement utilisés par RestFrontage — contextes de base de données, logger et service de fichiers — sont construits au démarrage. Il faut donc redémarrer RestFrontage pour que la surcharge soit utilisée par l’application.
Le fichier appsettings.Recovery.json peut contenir des secrets et ne doit pas être versionné. Une surcharge reste active à chaque redémarrage tant que sa clé demeure dans ce fichier. Corriger ensuite la configuration normale ne neutralise pas automatiquement une ancienne surcharge : il faut aussi retirer la clé correspondante du fichier de récupération.
10. Authentification par clé d’API - ApiKey
{
"ApiKey": [
{
"App": "Forge",
"Key": "<secret>",
"User": "AN=ServiceForge, OU=Users, DC=Immersive, DC=GraphicStream, DC=fr",
"From": "2026-01-01T00:00:00Z",
"To": "2027-01-01T00:00:00Z"
}
]
}
| Clé | Règle |
|---|---|
App |
Valeur attendue dans l’en-tête x-app-name. La comparaison ignore la casse. Une valeur vide désactive l’entrée. |
Key |
Valeur attendue dans x-api-key. La comparaison est sensible à la casse. Une valeur vide désactive l’entrée. |
User |
Distinguished Name exact d’un utilisateur existant dans la base de sécurité. Cet utilisateur devient l’identité de la requête. |
From |
Début inclus de validité. |
To |
Fin exclue de validité. |
Utiliser des dates ISO 8601 avec fuseau, idéalement en UTC avec le suffixe Z. La durée du JWT interne créé pour la requête est limitée au temps restant avant To.
11. SAML - Saml
{
"Saml": {
"FidUrl": "https://<fid>",
"FidSsoPath": "/<chemin-sso>",
"FidSloPath": "/<chemin-slo>",
"EntityId": "<identifiant RestFrontage declare dans la FID>",
"LoginUrl": "https://<restfrontage>/api/Saml/Login",
"LogoutUrl": "https://<restfrontage>/api/Saml/Logout"
}
}
| Clé | Rôle |
|---|---|
FidUrl |
URL de base de la fédération d’identité. |
FidSsoPath |
Chemin ajouté à FidUrl pour construire la requête de connexion SAML. |
FidSloPath |
Chemin ajouté à FidUrl pour construire la requête de déconnexion SAML. |
EntityId |
Émetteur déclaré dans les requêtes SAML. |
LoginUrl |
URL absolue de retour de connexion, placée dans AssertionConsumerServiceURL. |
LogoutUrl |
URL absolue de retour de déconnexion. |
12. OpenID - OpenID
{
"OpenID": {
"FidUrl": "https://<fid>/",
"FidAppId": "<client-id>",
"FidAppSecret": "<secret>"
}
}
| Clé | Effet réel |
|---|---|
FidUrl |
URL de base utilisée pour appeler les chemins relatifs tokeninfo et userinfo. Conserver un slash final. |
FidAppId |
Doit correspondre au client_id retourné par tokeninfo. |
FidAppSecret |
Est chargé dans le service, mais n’est actuellement envoyé dans aucun appel du contrôleur OpenID. |
13. Session
La session serveur est maintenant optionnelle. RestFrontage l’active seulement si la section Session contient au moins un paramètre : les services de session sont alors enregistrés et le middleware de session est ajouté après le routage.
Si la section est absente ou vide, RestFrontage n’enregistre aucun service de session et n’ajoute pas le middleware correspondant. Le fonctionnement reste donc identique à celui d’avant l’activation conditionnelle.
{
"Session": {
"IdleTimeout": "01:00:00",
"Cookie": {
"Name": "Immersive.Server.Session",
"HttpOnly": true,
"SameSite": "Strict",
"SecurePolicy": "Always"
}
}
}
| Clé | Rôle |
|---|---|
IdleTimeout |
Durée maximale d’inactivité des données de session. Une activité utilisant la session repousse cette échéance. |
Cookie:Name |
Nom du cookie technique contenant l’identifiant de session. |
Cookie:HttpOnly |
Empêche le JavaScript du navigateur de lire le cookie de session. Conserver true. |
Cookie:SameSite |
Contrôle l’envoi du cookie lors des navigations provenant d’un autre site. Strict est le réglage le plus restrictif. |
Cookie:SecurePolicy |
Avec Always, le cookie n’est envoyé qu’en HTTPS. |
La session utilise l’implémentation IDistributedCache déjà enregistrée par RestFrontage. Le cookie ne contient pas les données de session : il contient seulement un identifiant permettant de retrouver ces données dans le cache distribué.
Activer Session ne remplace pas l’authentification existante. Le cookie de session configuré ici est distinct du cookie d’authentification RestFrontage.Auth, dont la durée reste fixée à huit heures. Le middleware de session ne crée le cookie de session que lorsqu’un composant utilise effectivement HttpContext.Session.
Pour conserver explicitement le fonctionnement historique sans session, supprimer entièrement la section ou la laisser vide :
{
"Session": {}
}
Les clés reconnues sont :
Session:IdleTimeout;Session:Cookie:Name;Session:Cookie:HttpOnly;Session:Cookie:SameSite;Session:Cookie:SecurePolicy.
14. Gestion des secrets
Le fichier appsettings contient des valeurs qui peuvent être de vrais mots de passe SQL, une clé de compte Azure Storage, une clé Azure OpenAI et une clé JWT. Elles ne sont volontairement pas reproduites dans cette documentation.
Si ces valeurs sont actives ou ont été commitées, il faut les renouveler régulièrement. Au minimum, doivent être externalisés :
ConnectionStrings__ImmersiveModelContainer;ConnectionStrings__SecurityModelContainer;ConnectionStrings__ServerDatabaseContext;ConnectionStrings__LicenseModelContainer;LogsSettings__ConnectionString;IOSettings__ConnectionString;Application__JWTSecurityKey;Application__OpenAI__ApiKey;OpenID__FidAppSecret;ApiKey__0__Key, puis les index suivants ;IMMERSIVE_RECOVERY_KEY.
Les fichiers versionnés doivent conserver uniquement des valeurs de remplacement non fonctionnelles.
15. Exemple de production nettoyé
Cet exemple regroupe les paramètres RestFrontage utiles sans les rubriques ASP.NET Core standard :
{
"Database": {
"EnableLocalDB": false,
"EnableSqlite": false
},
"ConnectionStrings": {
"ImmersiveModelContainer": "<injecte hors du fichier>",
"SecurityModelContainer": "<injecte hors du fichier>",
"ServerDatabaseContext": "<injecte hors du fichier>",
"LicenseModelContainer": "<injecte hors du fichier>"
},
"Environment": {
"Name": "PROD",
"BackgroundColor": "#B00020",
"ForegroundColor": "#FFFFFF",
"Size": 6
},
"Recovery": {
"AccessKey": "<injecte via IMMERSIVE_RECOVERY_KEY>"
},
"SecurityDomainSynchronization": {
"VersionCheckInterval": "00:00:01"
},
"LogsSettings": {
"ProviderIdentifier": 10,
"IncludeScopes": true,
"IsEnabled": true,
"ContainerName": "Log",
"ConnectionString": "<injecte hors du fichier>"
},
"IOSettings": {
"Storage": "AzureBlob",
"ConnectionString": "<injecte hors du fichier>",
"ContainerName": "immersivecontent"
},
"Application": {
"Name": "RestFrontage PROD",
"AllowBlankPassword": false,
"PreWarmOrganizations": [],
"TokenLifetime": "08:00:00",
"JWTSecurityKey": "<injecte hors du fichier>",
"TaskManagerLoopIdleTime": 60,
"OpenAI": {
"Endpoint": "https://<ressource>.openai.azure.com",
"ApiKey": "<injecte hors du fichier>",
"AssistantName": "asst_<identifiant>",
"APIVersion": "2024-05-01-preview"
}
},
"ApiKey": [],
"Saml": {
"FidUrl": "https://<fid>",
"FidSsoPath": "/<chemin-sso>",
"FidSloPath": "/<chemin-slo>",
"EntityId": "<entity-id>",
"LoginUrl": "https://<restfrontage>/api/Saml/Login",
"LogoutUrl": "https://<restfrontage>/api/Saml/Logout"
},
"OpenID": {
"FidUrl": "https://<fid>/",
"FidAppId": "<client-id>",
"FidAppSecret": "<injecte hors du fichier>"
}
}
Les sous-sections OpenAI, ApiKey, Saml et OpenID peuvent être omises lorsque les fonctions correspondantes ne sont pas utilisées.
16. Contrôle avant mise en service
- Un seul mode de base est activé.
- Les chaînes portent exactement les noms attendus.
- La base des logs est configurée dans
LogsSettings:ConnectionString. -
JWTSecurityKeyest aléatoire, suffisamment longue et identique sur toutes les instances. -
AllowBlankPasswordvautfalseen production. - Aucun secret réel n’est stocké dans un fichier versionné.
- Les organisations de
PreWarmOrganizationsexistent réellement. - Les clés d’API possèdent une application, une clé, un utilisateur existant et une période valide.
- SAML contient bien les deux chemins
FidSsoPathetFidSloPath. - Les valeurs
???ont été remplacées avant d’activer SAML ou OpenID. - La section
Sessionest absente ou vide si aucune session serveur n’est souhaitée ; sinon son cookie est configuré pour HTTPS. - RestFrontage a été redémarré après une modification de connexion, de stockage, de logs ou de secret JWT.