Fonctionnement technique basique

JVC utilise 2 serveurs frontaux qui sont depuis le 7 mai 2022 protégés par le service "Cloudflare". Chaque serveur frontal utilise un serveur HTTP Apache2, tout ce qu'il y a de plus classique. En revanche, avant d'arriver sur le serveur Apache, on a plusieurs mailles dans la chaîne. En effet, lorsque vous faites une requête auprès de JVC, la chaîne suivante est effectuée avant d'arriver jusqu'au back-end :

Cloudflare => Round-robin entre les 2 serveurs frontaux => HAProxy => Apache2 => PHP / Express (Node.js)

Processus d'une requête HTTP

- Cloudflare est le premier point d'entrée pour accéder à JVC. Il gère les enregistrements DNS du site et ses IPs sont majoritairement aléatoires et anycastées/géocastées. Ce service touche la couche réseau/transport tout comme la couche applicative du modèle OSI : il fait office d'anti-DDoS à forte valeur (bien que JVC utilise le service "Volterra" en tant qu'anti-DDoS sur couches basses du côté des IPs de son AS 35717). Une partie de la couche applicative est protégée par Cloudflare, via des règles éditées manuellement par Webedia (entre autre, blocages de pools IPv4 de VPN connus, et de certains pays d'après certains retours d'utilisateurs).

- Un round-robin est effectué via Cloudflare auprès des serveurs DNS de Webedia. Le but est de déterminer de façon algorithmique quel serveur frontal va être utilisé pour la requête HTTP.

- HAProxy est un proxy et load-balancer TCP d'une efficacité remarquable, il est utilisé sur la totalité des environnements de production gérés par Webedia. C'est entre autre ce service qui peut vous retourner de sombres erreurs noires sur fond blanc comme "403 Forbidden". En effet, HAProxy fait aussi office de protection applicative (on peut donc en déduire que JVC utilisent plusieurs services sur couche haute pour protéger l'applicatif). On peut notamment remarquer le blacklistage des IPs du réseau "Tor", mais également le blacklistage des pools de l'AS 16276 (appartenant à la société OVH et n'étant utilisé que dans des contextes d'hébergement) - blocage mené suite à l'utilisation massive des services de la société OVH dans le but de scrapper / attaquer JVC.

- Apache2 est un serveur HTTP. Il a été optimisé par l'équipe technique actuelle de Webedia, mais également par l'ancienne équipe du site (on peut notamment citer Dargor et Haazel en tant que personnes ayant participées à l'élaboration de tunning du serveur HTTP).

- Le dernier point est selon la page qui est demandée. Des parties du site sont développées en PHP, et d'autres en Node.js. Pour anecdote, le site est hébergé côté serveur dans le dossier /opt/datas/sites/JEUXVIDEO.COM/. Il n'y a quasiment aucune protection de ce côté (si ce n'est une protection contre les IPs Tor).

Protection applicative Cloudflare

L'applicatif est donc, comme on a pu le voir, protégé par Cloudflare en premier point d'entrée. Cloudflare est binaire : si l'IP source est blacklistée, une HTTP 403 est retournée et l'accès à l'URI est refusé.
Le blocage est en outre simple à bypasser, pour le moment, on peut constater que l'usage d'IPs géolocalisées en France est un bon bypass.

JVC avant Respawn

Avant Respawn, JVC était développé sur plusieurs langages différents côté back-end : on peut citer le C, et le PHP. La base de données finale utilisait le moteur de base de données PostgreSQL. L'anarchie technique du back-end a menée au développement de Respawn (qui est également anarchique).

Les profils (CDV)

Les profils ("cartes de visite" / "CDV") étaient développés en PHP et avaient la particularité notable de stocker les données publiques de chaque utilisateur (par exemple, sa description personnelle) dans de simples fichiers HTML stockés sur disque : il n'y avait pas de requête SQL d'invoquée pour obtenir certaines données liées aux CDV. Lors de certains floods d'avis utilisateurs (notamment menés par UnifiedLinux et edwado), les CDV retournaient aléatoirement des pages blanches. La cause est toujours inconnue.

Les forums

Les forums étaient en C, et Dargor les nommaient "modulaires".

Les articles

Les articles n'étaient pas mis en ligne immédiatement après leur rédaction. Un système de "compilation" était nécessaire et à effectuer manuellement afin que le site "compile" les articles pour qu'ils deviennent accessibles au public. On peut imaginer que ce système de compilation a été développé dans un but de gestion de charge applicative.

Modération

La modération des forums était liée à une authentification à 2 étapes, menant à l'attribution du cookie mocoedivxuejdom permettant la modération de certains forums selon les permissions attribuées à chaque modérateur. Cette deuxième étape était une page spéciale réclamant 5 mots de passe, qui avaient la particularité d'être remplis de caractères aléatoires et spéciaux.

Authentification

Le cookie "wenvjgol" était utilisé pour l'authentification. Voir wenvjgol.

Respawn

Respawn a été développé entièrement en PHP côté back-end. Il utilise notamment des frameworks tels que Symfony côté forums, et des moteurs de templates tel que Twig. Respawn semble être divisé techniquement en plusieurs parties : en effet, on peut constater que certaines parties du site respectent le modèle vue-contrôleur (on peut citer les forums), bien que d'autres parties du site n'utilisent pas ce modèle et utilisent de l'url rewriting hardcodé dans des fichiers .htaccess. Respawn semble posséder une base de code identique entre JVC et ForumJV (désormais fermé), on pouvait constater de nettes interactions entre les 2 sites lorsque ForumJV était ouvert, interactions ayant menées à certains abus (ForumJV accordait des droits de modération sur son forum personnel, des failles de sécurité était donc existantes derrière ce privilège).

Schéma de base de données

Le schéma de base de données de Respawn semble anarchique et composé de mélange entre le Français et l'Anglais. Exemples de tables appartenant à Respawn : "get_compte_infos", "session_renew_v2", "jeu_get_v7". Notez le "v" à la fin de chaque table, laissant penser qu'il existe plusieurs versions de celles-ci.

Exemple d'appel en base de données

SELECT out_id_type, out_nom_type, out_dirname_type, out_affichage, out_date_publication, out_date_modification, out_id_alias_auteur, out_id_groupe_auteur, out_ip, out_titre, out_texte, out_commentaire, out_visibilite, out_liaisons, out_tags, out_medias, out_version, out_fiche, out_jeu, out_data, out_url, out_id_jeux FROM jeu_get_v7 WHERE id_contenu = xxx

Organisation technique

Comme dit précédemment, Respawn semble être un mélange de MVC et de code classique sans modèle particulier de respecté. Les fichiers du back-end sont également mitigés du côté de leur appellation, laissant encore droit au mélange entre Français et Anglais. Exemples de fichiers côté back-end :

/opt/datas/JEUXVIDEO.COM/htdocs/forums/liste_topic.php
/opt/datas/JEUXVIDEO.COM/app/modeles/core/OiPDOStatement.php
/opt/datas/JEUXVIDEO.COM/app/modeles/sso/Transaction.php
/opt/datas/JEUXVIDEO.COM/app/modeles/GoogleTagManager.php
/opt/datas/JEUXVIDEO.COM/app/modeles/sso/Compte.php
/opt/datas/JEUXVIDEO.COM/app/controllers/forum/liste_topic.php
/opt/datas/JEUXVIDEO.COM/app/modeles/sso/Session.php
/opt/datas/JEUXVIDEO.COM/app/vendor/...

Nommage des fonctions

Pour une énième fois, Respawn possède aussi des fonctions dont le nommage est entre le Français et l'Anglais. Exemples de fonctions côté back-end :

getInfoFromIdForum
loadMenu
checkMenuItem
getSingleton
getHtmlJeuForum
blocHtmlBoutiqueRandom

Optimisations

Le back-end PHP utilise Memcache (https://www.php.net/manual/fr/book.memcache.php) afin de faire baisser la charge technique de l'applicatif.

Stockage des utilisateurs

Depuis Respawn, les utilisateurs de JVC sont référencés sous un identifiant numérique côté base de données, contrairement au fonctionnement de l'ancien JVC où les utilisateurs étaient référencés par leur pseudo (pouvant mener à des posts sur les forums avec des pseudos identiques organisés différemment côté minuscules/majuscules). Vous pouvez obtenir votre ID via la page permettant d'éditer votre profil, l'ID est à la fin de l'URI.

Les forums

Les posts des forums sont déclarés sur plusieurs serveurs différents. Les IDs de ceux-ci semblent aléatoires (bien qu'un offset était attribué pour les posts présents sur ForumJV). Les IDs sont choisis selon l'emplacement dans lequel la ressource sera stockée lors de la création du topic. Le choix de l'emplacement se fait à la création du topic, les messages dans le topic sont alors stockés dans le même emplacement. Il semblerait qu'il y ait 8 emplacements. ID + 8 pour accéder à la ressource suivante, et ID - 8 pour accéder à la ressource précédente.

Exemple de messages séquentiels:

L'ID est incrémenté de 8 à chaque fois. Tous ces messages sont répertoriés dans le 7ème serveur (ID % 8, donc 905193382 % 8 = 6, 7ème).

À noter toutefois que les messages datant d'avant respawn sont complètement désordonnés, certainement dû à la migration durant respawn où la migration de ces messages a été effectué en parallèle.

Modération

La modération sur Respawn se nomme "Accès étendu". L'accès étendu peut être appelé via la page qui lui est dédiée : https://www.jeuxvideo.com/sso/auth.php ; il nécessite en revanche également un mot de passe, qui est envoyé via un lien sécurisé utilisable une seule fois par MP à chaque modérateur. A noter que le 103 est accessible à n'importe quel modérateur même sans authentification à l'accès étendu.

Authentification

Le cookie "coniunctio" est utilisé pour l'authentification.

Phoenix

Phoenix est une partie de JVC développée en Node.js. Elle semble de plus en plus abandonnée, et nous n'avons pas beaucoup d'informations à son sujet.