FAQ · TICKETS · CONTACT · CHANGELOG

Un problème ?
On est là.

Consultez la FAQ, ouvrez un ticket de support, ou contactez-nous directement. Pas de chatbot, pas de file d'attente: un opérateur vous répond.

Consulter la FAQ ↓ Ouvrir un ticket

..: Questions fréquentes

Avant d'écrire, la réponse est peut-être ici

Fonctions et architecture

Questions techniques sur le moteur XDP, les plugins, la sécurité, le système de frames et les conventions de développement BeamReactor.

À quoi sert frameheader() ?+

frameheader() ouvre une section visuelle (frame) dans la page. Elle affiche le titre du plugin ou de la section et crée le conteneur HTML dans lequel le contenu sera rendu. Usage : frameheader('Mon titre', 'h3', false). Les niveaux de titre suivent la hiérarchie HTML : h1 pour le titre de page (une seule fois), h2 pour les sections principales, h3 et au-delà pour les frames et widgets. Un plugin appelé directement doit commencer par : if($obj=='mon_plugin.php') frameheader($dialplugindisplay); — cette condition évite le double affichage du header quand le plugin est inclus depuis un autre script.

Quand utiliser framefooter() ?+

framefooter() ferme la frame ouverte par frameheader(). Elle est indispensable avant d'ouvrir une nouvelle section avec frameheader(). Ne jamais appeler framefooter() sans un frameheader() qui suit, sauf en fin de page. Le pattern classique pour structurer une page en plusieurs blocs : frameheader('Section 1'); /* contenu */ framefooter(); frameheader('Section 2'); /* contenu */. Le moteur gère la fermeture finale automatiquement.

Comment structurer une page en plusieurs sections ?+

Utilisez la paire framefooter() / frameheader() pour enchaîner les sections. Chaque section crée un bloc visuel distinct avec son propre titre. Exemple : après avoir affiché un formulaire et reçu une erreur, fermez la frame courante avec framefooter(), ouvrez une nouvelle frame propre avec frameheader(''), incluez le formulaire à nouveau, puis faites return. Cela maintient l'utilisateur dans une page valide et encadrée sans redirection HTTP.

Comment fonctionne secure() ?+

secure() vérifie si le niveau de l'utilisateur connecté est suffisant pour accéder à une ressource. Elle prend en paramètre une constante de niveau (BASE_LEVEL_ADMIN, PLUGIN_LEVEL_MODERATOR, etc.) et retourne true ou false. Le pattern standard : frameheader($dialplugindisplay); if(!secure(PLUGIN_LEVEL_MODERATOR)) { forbids(); return; }. La frame est ouverte AVANT la vérification — forbids() s'affiche dans la frame, sinon le layout est cassé. L'astuce secure(0) vérifie simplement si l'utilisateur est connecté.

Quels includes utiliser dans un plugin ?+

Aucun pour la config et les librairies — le moteur XDP les charge automatiquement. Le seul include autorisé est celui de la locale : include(getlocale('nom_du_plugin'));. Les fichiers .conf.inc.php et .lib.inc.php sont détectés et chargés par le moteur. Faire un require ou include manuel pour la config ou les libs provoquera un warning et un chemin cassé. De même, ne jamais inclure un module (.mod.php) — ils sont appelés exclusivement via ?obj=nom.mod.

Comment fonctionnent les traductions dans un plugin ?+

Chaque plugin a ses fichiers de traduction dans /locale/nom_du_plugin.XX.inc.php (XX = code langue ISO). Le chargement se fait via include(getlocale('nom_du_plugin'));, à appeler AVANT frameheader() pour éviter les erreurs de variable manquante. Les traductions utilisent un tableau $dialnomplugin[]. $dialplugindisplay contient le titre affiché du plugin, $dialplugincall le nom dans le centre de contrôle. getAvailableLanguages() retourne la liste des langues disponibles.

Comment charger du CSS ou du JavaScript spécifique à un plugin ?+

Utilisez la variable globale $headdata pour injecter dans le <head> : $headdata .= '<link rel="stylesheet" type="text/css" href="plugins/mon_plugin/css/mon_plugin.css">'; Pour le JavaScript, même principe : $headdata .= '<script src="plugins/mon_plugin/js/mon_plugin.js"></script>'; Pour exécuter du JS après le DOM, utilisez $footdata avec un heredoc. Les CSS doivent utiliser les variables définies dans core.css — ne jamais inventer de couleurs. Si une variable manque, proposez de l'ajouter à core.css.

Comment valider les entrées utilisateur ?+

Utilisez le Sanitizer : use Beamreactor\Sanitizer\Parser; puis Parser::sanitize($input, 'type'). Les types disponibles incluent : bool, date, email, name, html, xml, uuid, url, string, ip, float, int, path et d'autres. sanitize() nettoie et valide la donnée, retournant false si invalide. check() vérifie le format sans nettoyer. Toujours sanitizer AVANT toute opération SQL. Ne jamais inventer de datatype — proposez-en un si nécessaire.

Comment interagir avec la base de données ?+

Utilisez la classe SQL : use Beamreactor\Database\SQL;. Méthodes principales : SQL::query() pour plusieurs lignes, SQL::queryFirst() pour une seule ligne, SQL::queryValue() pour une valeur unique, SQL::insertRow() pour insérer, SQL::updateRow() pour mettre à jour, SQL::deleteRow() pour supprimer. Toujours utiliser des requêtes préparées avec des paramètres ?. La concaténation directe de variables dans le SQL est strictement interdite. Vérifiez que la BDD est disponible avec isset($cfg['dbtable']) et que votre table existe avec SQL::tableExists().

Comment créer un endpoint AJAX ?+

Les modules (.mod.php) sont les endpoints AJAX de BeamReactor. Ils répondent en JSON, XML, HTML ou texte. Ils sont placés dans /handlers/nom_plugin.mod.php et appelés via ?obj=nom_plugin.mod (sans le .php). Ne jamais appeler le chemin complet du fichier. Structure minimale : vérification frameheader, sécurité avec secure(), header Content-Type, traitement de l'action via Parser::sanitize(), réponse JSON avec ['success' => !!1] ou ['success' => !!0]. Côté JavaScript, l'appel se fait avec $.post(BEAM_BASE_URL + '?obj=nom_plugin.mod', {...}).

Comment fonctionne le routage des pages ?+

Tout dans BeamReactor passe par index.php. Le paramètre ?obj= détermine ce qui est chargé. Un plugin : ?obj=mon_plugin.php. Un module AJAX : ?obj=mon_plugin.mod. Un document : ?obj=ma_page.dta. Le moteur XDP résout le chemin, charge la config, les libs et la locale automatiquement, puis exécute le script dans un environnement sécurisé. Aucun script PHP ne peut être appelé directement — tout passe par le moteur.

Comment afficher des notifications à l'utilisateur ?+

BeamReactor dispose d'un système de toasts avec 6 niveaux : debug (0), info (1), success (2), warning (3), error (4), critical (5). Usage rapide : Toast::info('Titre', 'Message', 5000); ou Toast::add(Toast::LEVEL_WARNING, 'Titre', 'Message', BASE_LEVEL_USER, 0). Le paramètre minUserLevel permet de cibler les notifications par niveau d'accès. La durée est en millisecondes, 0 pour persistant.

Quelle est la structure d'un plugin BeamReactor ?+

Un plugin est un dossier autonome dans /plugins/nom_du_plugin/ contenant : nom_du_plugin.php (interface principale), /conf/ (configuration auto-chargée), /lib/ (bibliothèques auto-chargées), /locale/ (traductions par langue), /handlers/ (endpoints AJAX .mod.php), /css/, /js/, /images/, /sql/ (installation des tables), /tests/, /doc/ (documentation .md et aide .help.json), et /data/cache/ pour les données persistantes. L'installation consiste à déposer le dossier. La suppression consiste à le retirer.

Comment afficher des dialogues JavaScript dans BeamReactor ?+

BeamReactor remplace les alert/confirm/prompt natifs par des dialogues personnalisés définis dans javascript/dialogs.js.php. Quatre fonctions : alertWindow('Titre', 'message') pour une alerte, confirmWindow('Titre', 'question ?', {}, callback) pour une confirmation, promptWindow('Titre', 'Label :', {}, callback) pour une saisie, infoWindow('Titre', 'info') pour une information. Ne jamais utiliser alert(), confirm() ou prompt() natifs.

Comment passer les traductions PHP au JavaScript ?+

Dans le fichier locale du plugin, définissez un tableau $js_translations et appelez setJavascriptLocale($js_translations). Exemple : $js_translations = ['mon_plugin' => ['error_msg' => $dialmonplugin[5]], 'global' => ['error' => $dial[32]]]; setJavascriptLocale($js_translations);. Côté JavaScript, accédez aux traductions via PLUGIN_TRANSLATION.mon_plugin.error_msg. Les traductions sont injectées dans le head comme un objet JavaScript global.

Puis-je utiliser exit ou die dans un plugin ?+

Non. Les plugins ne peuvent jamais utiliser exit ou die. Le seul exit autorisé dans tout le code d'un plugin est if(!function_exists('frameheader')) die('forbidden'); en première ligne, qui vérifie le contexte BeamReactor. Pour interrompre l'exécution, utilisez return. Pour gérer une erreur, affichez le message dans la frame puis faites return. Si un plugin utilise exit ou die, le moteur ne peut pas savoir ce qui a échoué et le diagnostic devient impossible.

Comment fonctionnent les niveaux de sécurité ?+

BeamReactor utilise une hiérarchie fixe : OVERMIND > ADMIN > MODERATOR > HIGHUSER > USER. Les constantes BASE_LEVEL_* sont définies dans cog.inc.php. Chaque plugin peut définir ses propres niveaux via NOM_PLUGIN_LEVEL_* dans sa configuration. $basedisplevel utilise toujours BASE_LEVEL_*, jamais PLUGIN_LEVEL_*. Les define() custom se font après $basedisplevel. Le système complète automatiquement les niveaux manquants via base_user_levels().

Comment fonctionne le chargement automatique des classes ?+

Les fichiers .lib.inc.php et .conf.inc.php sont chargés automatiquement par le moteur. Pour des classes supplémentaires, enregistrez un autoloader PSR-4 dans la configuration du plugin avec spl_autoload_register(). Le namespace suit la convention Beamreactor\NomPlugin\. Les fichiers de classe vont dans /lib/ et sont résolus par le chemin relatif au namespace. Cela permet à plusieurs plugins de cohabiter sans collision de noms.

Authentification à deux facteurs (2FA)

Elle ajoute une couche de protection indispensable en exigeant une preuve d'identité supplémentaire. Elle garantit que même en cas de vol de votre mot de passe, l'accès à vos données reste impossible pour un tiers. C'est le rempart le plus efficace contre les tentatives d'usurpation d'identité et de piratage de compte.

Comment se connecter avec l’authentification à deux facteurs ?+

Pour sécuriser votre compte, deux étapes sont nécessaires. Les utilisateurs enregistrés doivent se connecter à l'interface principale de BeamReactor. En cliquant sur le bouton "profil" en haut à gauche, vous accédez à votre profil. En bas se trouve un QRcode 2FA à scanner avec une application comme Google Authenticator ou Microsoft Authenticator. Des codes spéciaux de récupération seront disponibles : recopiez-les précieusement pour récupérer votre compte en cas de perte ou de vol de votre téléphone.

Comment me connecter avec l’authentification à deux facteurs ?+

Connectez-vous avec votre nom d'utilisateur et mot de passe sur le site BeamReactor. Le système vous demandera ensuite de rentrer un code que vous trouverez dans l'application Authenticator de votre téléphone.

Quelles sont les conditions à respecter ?+

Mettez à jour votre système d’exploitation et l’application Authenticator vers leurs dernières versions. Si vous n’arrivez pas à vous connecter mais avez accès à votre email, essayez de changer votre mot de passe. Sinon, contactez-nous via le formulaire de support.

Et si j’ai oublié mon mot de passe ?+

Vous pouvez le réinitialiser à tout moment en cliquant sur le lien "compte inaccessible" sur la page de connexion.

Et si mon téléphone est perdu ou cassé ?+

Utilisez l'un de vos codes de secours fournis lors de l'enregistrement 2FA. Sur la page d'authentification, cliquez sur "code de secours", entrez-le, puis mettez à jour votre profil une fois connecté.

Et si j’ai un nouveau numéro de téléphone ?+

La procédure est identique à celle d'un téléphone perdu : utilisez vos codes de secours pour vous connecter, puis synchronisez votre nouvel appareil via votre profil utilisateur.

Pourquoi l’authentification à deux facteurs est-elle mise en place ?+

L'authentification à deux facteurs (2FA) ajoute une couche de protection indispensable en exigeant une preuve d'identité supplémentaire. Elle garantit que même en cas de vol de votre mot de passe, l'accès à vos données reste impossible pour un tiers. C'est le rempart le plus efficace contre les tentatives d'usurpation d'identité.

..: Recherche

Cherchez dans toute la documentation

..: Assistance

Besoin d'aide personnalisée ?

Ticketing — Pour les utilisateurs enregistrés. Créez un ticket, suivez son avancement, échangez avec le support technique. Votre historique est conservé.

Contact direct — Pour les demandes commerciales, les partenariats ou les questions avant achat. Pas besoin de compte.
Formulaire de contact →

..: Dernières modifications

Changelog récent

- June 23, 2026, 12:50 am: Updated WriteNotepad MCP tool to properly align with the database-driven implementation and user pseudonymization (HMAC-SHA256) instead of using flat files.
- June 22, 2026, 11:36 pm: Secured versions.rss.php using fleet_peers database to validate remote sites and track their last_seen timestamp.
- June 22, 2026, 11:23 pm: Fixed HTTP response codes being lost during the final output buffer assembly in index.php (ensures 403, 404, etc. are properly sent to the client instead of reverting to 200). Added whitelist in hax.inc.php to prevent Updater from being banned.
- June 22, 2026, 10:47 pm: Removed stray print_r in updater manifest fetch and added display of cURL/HTTP errors in the DOM if fetching the update manifest fails.
- June 22, 2026, 1:28 am: Fixed type error in SiteIndexer::extractContentFromHTML where MdParser returned an array instead of a string.
- June 20, 2026, 3:34 pm: Mise à jour du notepad (comportement général, obfuscation des noms plus robuste), des css du plugin todo, de certaines locales
- June 20, 2026, 3:25 pm: Planifié : création d'un outil MCP pour l'accès au calendrier, avec restriction des permissions à l'utilisateur courant.
- June 13, 2026, 1:20 pm: Mise à jour du calendrier (changement des locales pour déplacer la logique d'affichage des catégories)
- June 13, 2026, 1:19 pm: Readded Grok to the MCP with the proper grok/gpt routing. Fixed the MCP for RTE compatibility. Updated the RTE
- June 11, 2026, 12:19 am: Creation de 2 mini plugins pour l'entrainement aux verbes irréguliers Allemands et au vocabulaire Anglais. Reimplémentation de la skin CSS1 pour rendre la structure claire pour des développeurs tiers. Mise à jour de la classe Calendar pour permettre le déclenchement d'évènements corrélés liés à la classe TODO et à la CMDB. Reflexions autour d'un module STIX d'export de tentatives d'attaques pour synchronisation vers des systèmes de syndication globaux.
- June 11, 2026, 12:15 am: Fixed potential XSS vulnerabilities in the CAP Parser and updated the rss_syndicator. Updated the URL datatype to force a scheme. Removed some calls to the now deprecated cleandata function. Updated the Claude/Anthropic compatibility model. updated the prompt for Gemini that would refuse to work under certain circumstances"
- May 28, 2026, 8:45 pm: Implicit conversion from float 104.25311203319502 to int loses precision (error_logger)
- May 27, 2026, 11:40 pm: Grosse opération de réduction des zones d'attaque potentielles en transferant les locales vers un format JSON:\n\nRename mécanique des $dialXX historiques → $dial<plugin_literal> partout (104 plugins traités, ~1500 occurrences).\ngetlocale() étendu pour gérer JSON en priorité + fallback .inc.php.\nCache plugins.cache.php étendue: porte plugin_meta[lang][plugin] avec meta extraite par regex. login_success et plugin_catalog passent de N includes/requête à un lookup tableau (optimisation de chargement).\nPattern déclaratif _plugincall_query + _plugincall_template.\nHistorique modifié pour permettre la soumission de paragraphes complets.
- May 22, 2026, 4:38 pm: Modification de la page d'accueil BeamReactor pour montrer la compatibilité LLM universelle tant côté MCP que tiers/fournisseur/interne (auto hébergée) avec configuration simple.
- May 22, 2026, 3:38 pm: Fix de l'export SQL(mauvais échappement de backslash multiples)
- May 20, 2026, 10:31 pm: Implementation du couple frameheader/framefooter dans le mdreader, mise en valeur des blocs de code, changement de structure de certaines includes pour limiter les temps de chargement au strict nécessaire.
- May 19, 2026, 5:48 pm: Reorganisation des plugins. Banna, intrusion_scanner, parser_enforcer, audit, bans_sync, fleet_peers passent dans la catégorie sécurité, Invoices dans la boutique, support tickets dans communauté...
- May 19, 2026, 5:31 pm: Table fleet_peers pour les ciphers, remise en place du système de partage des bans pair a pair dans la flotte des sites BeamReactor, meilleur usage du parser dans banna, statistics, abuse. Mise en place de la catégorie 10 "sécurité" pour le tableau de bord.
- May 12, 2026, 7:34 pm: 'fixed issues with the custom LLM demo plugin
- May 12, 2026, 7:33 pm: Amélioration des traductions Java, retrait de l'ancien système 2FA, mise en place des fonctions forensic dans le datatype string ainsi que des forensicDecode et forensicRender dans le Parser, affichages sécurisés dans current_user et banna en utilisant les nouvelles fonctions forensic basées sur les defense logs, passage des includes en camelCase, fixed missing versions in misc JS files, js versions are now handled by the versions.rss, fixe
- May 10, 2026, 6:12 pm: Nombreuses mises à jour du systeme de bans pour activer le fitlrage cidr au niveau de ban.inc.php, correctifs d'aspects dans les dta d'Aegis pour l'affichage téléphonie portable, déplacement de last_visitors de la table stats vers la table defense_logs pour eviter l'anonymisation, mise à jour de current_users pour ignorer le webmaster
- May 4, 2026, 12:50 pm: Refactored PHPDoc dates from YYYY-MM-DD to YYYY.MM.DD across 679 files.
- May 3, 2026, 2:06 pm: Enième mise à jour de Payment/PaymentStripe. Mise à jour du MCP pour permettre l'intervention sur le code, avec une fenêtre modale pour chaque intervention. Persona "system". Lien entre ContextHelper et MCP pour récuperer les profils, les historiques et stocker les interventions MCP dans l'environnement LLM général.
- April 27, 2026, 10:14 pm: class session, changement de isAuthenticated() (utilisé pour le chargement de classes JS) pour favoriser l'usage de la méthode secure() originale.
- April 27, 2026, 10:13 pm: Mise à jour des loaders, retrait des fonctions inutiles autoDiscoverAll() et discoverPlugins(). Correction du 2FA, implémentation du générateur de code QR et de l'endpoint correspondant pour éviter la dépendance externe. Correction de la classe TwoFA pour prendre en compte ces modifications. Retrait de TOCTOU dans la classe CMDB (createOwner(), register(), subscribe()). Changement du nom de cookie de session, changé un rand() par un random_bytes(
- April 26, 2026, 1:35 pm: Rectification de race conditions (TOCTOU DB) dans les modules stripe et paypal. Mise en place d'un upsert dans la classe SQL.
- April 22, 2026, 11:25 pm: Fix du flow et des valeurs TTC sur l'ensemble du système marketing. Mise à jour des pages d'accès BeamReactor
- April 19, 2026, 10:36 pm: Correction des affichages TTC, correctifs (multiples) de la structure d'abonnement stripe, des classes et des plugins y afférents (*order*, payment, products_order_check, products_order_confirm)... Ajout du JSON VIES à la table 'orders'.
- April 19, 2026, 10:33 pm: Remplacement de l'array des strings VIES par un module (endpoint) VIES approprié avec check du numéro de TVA intra à chaque étape.
- April 14, 2026, 12:59 pm: Mise en place de la facturation numérique. Meilleure prise en compte des abonnements liés a l'achat de produits via Stripe (avant partiellement manuel, maintenant entièrement automatisé).

Historique complet →

Pas trouvé votre réponse ?

Ouvrez un ticket ou contactez-nous.

Ouvrir un ticket → Nous contacter

Un problème ?On est là.