Pare-feu et résidence des données.

DXPR Builder stocke vos pages dans votre propre base de données Drupal. Il contacte les services DXPR pour les contrôles de licence, les assets de l’éditeur et les requêtes IA. Cette page liste chaque connexion, ce que chacune transporte, où tournent les modèles DXAI Kavya, comment la clé produit est stockée, et ce qui marche quand l’accès sortant est restreint.

Connexions en bref

Toutes les connexions utilisent HTTPS sur le port 443. Les visiteurs du site ne chargent jamais rien depuis les serveurs DXPR : les pages publiées sont rendues depuis du HTML stocké dans la base de données, et le script frontal (dxpr_builder/dxpr_frontend.min.js) est livré dans le module. app.dxpr.com n’apparaît que dans des liens montrés aux administrateurs.

Contrôles de licence (dxpr.com)

Le serveur Drupal appelle quatre endpoints définis dans src/Service/DxprBuilderLicenseServiceInterface.php, chacun avec la clé produit en en-tête Authorization: Bearer.

Le contenu des pages ne fait jamais partie d’une requête de licence. Le module imprime aussi un <div> caché sur la page d’accueil contenant une chaîne marqueuse fixe, la tranche de licence, le nombre de rédacteurs et le nombre d’enregistrements (dxpr_builder_page_bottom() dans dxpr_builder.module). Il est lisible dans le code source de la page.

Assets de l’éditeur (cdn2.dxpr.com, cdn.dxpr.com)

Quand Editor Assets est sur Cloud (par défaut), le navigateur du rédacteur charge le JavaScript et le CSS du constructeur depuis https://cdn2.dxpr.com/<version>/, avec repli sur https://cdn.dxpr.com/<version>/ après une sonde /health échouée. La clé produit est ajoutée à chaque URL d’asset comme paramètre de requête jwt (dxpr_builder_library_info_build()). Le CDN vérifie cette clé : une réponse 401 fait afficher « Your product key is not valid » à js/editor_validation.js.

Les options Local (minified) et Local (unminified) n’apparaissent sur le formulaire de paramètres que quand une copie compilée de l’éditeur existe dans le répertoire dxpr_builder/ du module, et une telle copie est utilisée automatiquement même quand Cloud est choisi. Le dépôt git ne suit pas ces fichiers compilés, une version téléchargée depuis drupal.org charge donc l’éditeur depuis le CDN.

Requêtes IA (kavya.dxpr.com)

Le navigateur ne contacte jamais kavya.dxpr.com. L’éditeur poste vers des routes sur votre propre site (/dxpr_builder/ajax/ai/chat, /dxpr_builder/ajax/ai/image, /dxpr_builder/ajax/ai/image/edit ; toutes exigent la permission edit with dxpr builder, un jeton CSRF et un compte sous licence). Le site relaie chaque requête via le fournisseur DXPR du module Drupal AI (ai_provider_dxpr) vers https://kavya.dxpr.com/v1/chat/completions, /v1/images/generations ou /v1/images/edits, authentifié avec la clé API DXPR stockée dans le module Key. Le paramètre host du fournisseur (ai_provider_dxpr.settings) peut pointer les requêtes vers un autre hôte. Séparément, la page des paramètres IA appelle GET https://kavya.dxpr.com/v1/account/balance avec la clé produit pour montrer votre solde de crédits.

Ce qu’une requête IA contient

Seules les fonctions IA envoient du contenu de page hors du site, et seulement quand un rédacteur les déclenche (dxpr_builder/build/dxpr-global/ai-service.js).

Deux utilitaires récupèrent des pages web depuis le navigateur du rédacteur (ai-service-url-fetch.js) : une URL dans un prompt est demandée avec .md ajouté et, en cas d’échec, via https://r.jina.ai/<url>, un service de lecture tiers non exploité par DXPR ; un prompt qui demande de cloner une page envoie l’URL à https://html-extract.dxpr.com/?url=.... Dans les deux cas, seule l’URL est envoyée.

La sortie IA est filtrée au retour. Domaines autorisés, balises bloquées et balises autorisées se définissent à /admin/dxpr_studio/dxpr_builder/ai_settings sous AI Output Filtering.

Où tournent les modèles DXAI Kavya

DXPR Builder propose trois modèles (src/Constants/AiModelConstants.php) :

Il n’y a aucun paramètre de région dans aucun module. La résidence des données se choisit par modèle et par les fournisseurs en amont activés :

• kavya-m1 bascule entre cinq fournisseurs, listés avec leur pays dans le formulaire de paramètres DXPR AI Provider : Anthropic (États-Unis), Google Gemini (États-Unis), MistralAI (France), OpenAI (États-Unis), XAI (États-Unis). En mode Manual priority, vous glissez les fournisseurs entre Enabled et Disabled et définissez leur ordre.
• kavya-m1-eu n’utilise que MistralAI. Le README DXPR AI Provider dit qu’il « keeps data within European boundaries (servers in Netherlands) » ; sa documentation dit que le serveur Kavya tourne aux Pays-Bas avec un secours en Allemagne, que les requêtes passent par les serveurs MistralAI en France, et qu’il ne rebascule jamais vers un fournisseur non-UE. Ces emplacements sont documentés par DXPR, pas imposés par quoi que ce soit dans le code Drupal.

Avec ai_provider_dxpr installé, le modèle se choisit à /admin/config/ai/providers/dxpr, et son paramètre allowed_models contrôle quels modèles les rédacteurs peuvent choisir. Sans lui, modèle et ordre des fournisseurs se définissent à /admin/dxpr_studio/dxpr_builder/ai_settings.

Comment la clé produit est stockée

La section License de /admin/dxpr_studio/dxpr_builder/settings propose deux options de Storage method (src/Form/DxprBuilderSettingsForm.php, src/Service/DxprBuilderKeyService.php) :

• Key module : la clé est lue depuis l’entité Key choisie sous Key. dxpr_builder_update_9020() déplace une clé trouvée dans dxpr_builder.settings vers l’entité Key dxpr_builder_jwt, dont le fournisseur Configuration l’exporte toujours. Seul le fournisseur File ou Environment garde la clé hors des exports de configuration.
• Configuration storage : la clé est enregistrée en clair comme dxpr_builder.settings.json_web_token et est incluse dans les exports de configuration.

La clé produit est un JSON Web Token qui authentifie les appels de licence, l’appel de solde de crédits et les URL d’assets CDN ; traitez-la comme un secret.

Configuration du pare-feu

L’analytique (dxpr_builder/build/dxpr-analytics/, PostHog) identifie les événements par l’adresse e-mail du rédacteur et le nom d’hôte du site. Désactivez-la avec drush config:set dxpr_builder.settings record_analytics 0 ; la clé n’a pas de champ de formulaire. Deux autres clés sans champ de formulaire sont lues depuis dxpr_builder.settings : cloud_url remplace l’URL de base du CDN (VERSION est substitué avec la version du module) et license_endpoint remplace l’endpoint central de stockage des utilisateurs. Définissez-les avec un remplacement de configuration dans settings.php.

Configuration du proxy

Les appels de licence et IA utilisent le client HTTP de Drupal, un proxy se configure donc dans settings.php :

$settings['http_client_config']['proxy'] = [
  'http' => 'http://proxy.example.com:8080',
  'https' => 'http://proxy.example.com:8080',
  'no' => ['localhost', '127.0.0.1'],
];

Les navigateurs des rédacteurs chargent les assets CDN et appellent directement les services d’analytique et de lecture, ces requêtes suivent donc les paramètres proxy du poste de travail.

Déploiements isolés et sur site

DXPR Builder tourne sur votre propre serveur ; aucun contenu ne passe par un composant hébergé. Quand ni le serveur ni les rédacteurs ne peuvent joindre DXPR :

Sans aucune clé produit, le module applique en code les limites du niveau gratuit : un rédacteur et 100 éléments de contenu.

Un déploiement entièrement sur site marche donc pour servir et stocker du contenu ; la modification a besoin d’un accès CDN ou d’une compilation locale de l’éditeur, et la validation de licence a besoin de dxpr.com. Contactez DXPR si une compilation de l’éditeur à héberger en interne est nécessaire.

Et ensuite ?

• Installation : configurer la clé produit et la méthode de stockage
• Fonctions IA : activer l’IA et choisir un modèle
• Sécurité : permissions et filtrage de sortie
• Licence et clé produit : dépanner les erreurs de licence