V0.8.2 — Relecture des enregistrements

Pourquoi

Depuis la 0.8.0 et la 0.8.1, le Site enregistre en continu et suit l’espace et les débits, mais l’Administrateur ne pouvait pas relire cet historique : la seule preuve était l’inspection du volume Docker. Il lui fallait choisir un moment sur la Conservation et lire la vidéo d’une Caméra depuis ArgOS.

Ce qu’on peut faire maintenant

• Relire l’historique d’une Caméra depuis l’onglet Enregistrement : un clic sur sa ligne du résumé ouvre sa timeline sur toute la Conservation.

  

• Voir d’un coup d’œil où il y a de la vidéo : plages enregistrées en couleur, trous en gris ; le Segment en cours d’écriture n’est pas proposé, et les Segments fermés depuis apparaissent seuls (rafraîchissement toutes les 10 s).

  

• Cliquer un moment sur la timeline pour lire le Segment qui le couvre, depuis son début ; au clavier, Entrée ou Espace sur la timeline passe au Segment suivant.

  

• Cliquer dans un trou pour lire le Segment le plus proche.

  

• Mettre en pause et reprendre, en suivant la progression dans le Segment.

  

• Accélérer à ×2, ×4, ×8 ou ×16 pour parcourir vite une longue Conservation.

  

• Laisser la lecture enchaîner seule sur le Segment suivant, à la même vitesse.

  

• Relire sans réencodage ; un poste qui ne décode pas le H.265 le dit clairement, comme au Live.

  

• Comprendre l’absence de vidéo : une Caméra sans enregistrement affiche « Aucun enregistrement sur cette période ».

  

• Relire seulement derrière la session : une session expirée renvoie à la connexion, rien n’est relu.

  

Historique des tickets

• PR : #132
• Commits : https://github.com/UlyssouLV/ArgOS/pull/132/commits

Tickets (Fixes) : #127 #128 #129 #130 #131

Hors périmètre

Téléchargement / export des enregistrements (Plus tard), relecture de plusieurs Caméras à la fois, seek précis à la seconde dans un Segment (refonte 1.0.0), vitesse ×32, réencodage H.265 → H.264, plages horaires d’enregistrement, bind mount / second disque. Lecture réelle du H.265 non jouée aux tests humains (seul le message « ne lit pas le H.265 » l’a été).

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.8.2/docs/specs/v0.8.2-relecture-des-enregistrements.md

ADRs de cette version (liens sur ce tag, pas la base) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.8.2/docs/adr/0013-relecture-des-enregistrements.md

Issues laissées de côté (PR / spec hors périmètre) : #86 #95

V0.8.1 — Suivi du stockage et du débit d'écriture

Modifié en V0.8.2 (#127) — Page Enregistrement
Avant : Dashboard stockage / débits / réglages seulement
Après : + sélection Caméra, timeline et viewer de relecture

Pourquoi

L'enregistrement continu (0.8.0) écrivait sur un volume Docker sans vue d'ensemble : pas d'espace disque visible, conservation figée à 1 h, aucun débit pour savoir si une conservation plus longue tient. L'Administrateur découvrait le problème quand l'écriture passait en erreur.

Ce qu'on peut faire maintenant

• Ouvrir l'onglet Enregistrement pour suivre l'espace disque du volume (total / libre / utilisé) sans passer par la liste des Caméras.
• Régler la conservation Site (1–24 h) et un seuil de place libre ; un bandeau avertit sous le seuil sans couper l'enregistrement.
• Lire les débits d'écriture (mesurés sur les segments quand c'est possible) pour les Caméras qui enregistrent, plus une projection si toutes les Caméras actives enregistraient, avec une tenue estimée confrontée à la conservation.
• Voir un résumé par Caméra (nom, état, débit) sur Enregistrement ; garder le geste ON/OFF et le détail chemin / âge dans Administration.

Historique des tickets

• PR : #126
• Commits : https://github.com/UlyssouLV/ArgOS/pull/126/commits

Tickets (Fixes) : #121 #122 #123 #124 #125

Hors périmètre

Relecture des enregistrements (0.8.2), plages horaires, bind mount / second disque, coupe automatique au seuil, bugs #86 et #95.

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.8.1/docs/specs/v0.8.1-suivi-du-stockage-et-du-debit-decriture.md

ADRs de cette version (liens sur ce tag, pas la base) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.8.1/docs/adr/0012-suivi-stockage-et-conservation-reglable.md

Issues laissées de côté (PR / spec hors périmètre) : #86 #95

V0.8.0 — Enregistrement continu

Modifié en V0.8.2 (#127) — Exposition HTTP des segments
Avant : Pas d’exposition HTTP ; inspection volume seulement
Après : Relecture UI authentifiée (serveur playback du pont relayé par nginx derrière la session, ADR 0013)

Modifié en V0.8.1 (#121) — Conservation des segments
Avant : Fixe 1 h (recordDeleteAfter: 1h), non réglable depuis l'UI
Après : Conservation Site 1–24 h (défaut 1 h), poussée au pont

Pourquoi

Un Site ArgOS diffuse déjà le Live des Caméras, mais ne garde rien sur disque. L'Administrateur ne pouvait pas enregistrer en continu le Flux des Caméras choisies, ni vérifier qu'un enregistrement écrit bien des fichiers — et le pont ne tirait le RTSP que lorsqu'on regardait.

Ce qu'on peut faire maintenant

• Allumer ou couper l'enregistrement continu d'une Caméra depuis l'Administration (interrupteur + indicateur à l'arrêt / enregistre / en erreur).
  
• Voir le chemin du dossier (/enregistrements/camera-<id>) et l'âge du dernier segment, sans ouvrir le Live.
  
  
• Conserver les segments déjà écrits quand on coupe l'enregistrement ou qu'on désactive la Caméra ; purger le dossier à la suppression.
  
  
• Continuer à regarder le Live des autres Caméras pendant qu'une Caméra enregistre.
  
• Voir un échec d'écriture (Flux mort, etc.) comme en erreur.
  
• Inspecter les fichiers fMP4 dans le volume Docker nommé enregistrements (segments ~1 min, rétention 1 h, sans réencodage) — pas de téléchargement ni de relecture dans l'UI.
  
  

Historique des tickets

• PR : #120
• Commits : https://github.com/UlyssouLV/ArgOS/pull/120/commits

Tickets (Fixes) : #115 #116 #117 #118 #119

Hors périmètre

Page Enregistrement / suivi stockage et débits (0.8.1) ; réglage UI de la durée de conservation ou d'un seuil disque ; relecture depuis l'UI (0.8.2) ; bind mount vers un dossier hôte ; téléchargement HTTP des segments ; filet automatique si disque plein ; plages horaires ; bugs #86 et #95.

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.8.0/docs/specs/v0.8.0-enregistrement-continu.md

ADRs de cette version (liens sur ce tag, pas la base) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.8.0/docs/adr/0011-enregistrement-continu-par-mediamtx.md

Issues laissées de côté (PR / spec hors périmètre) : #86 #95

V0.7.2 — Livraison continue

Pourquoi

Depuis la 0.7.0, un Site Ubuntu s'installe sans le dépôt, mais les images arrivaient encore par docker save / docker load, et la mise à jour restait manuelle. Sans registre publié ni promotion d'un digest déjà vert, on ne pouvait ni poser un vrai Site qui se met à jour après une Release, ni refermer clairement l'isolement réseau des caméras (VLAN).

Ce qu’on peut faire maintenant

• Publier et tirer les quatre images du Site (api, web, pont, certificats) sur ghcr.io en multi-arch (amd64 + arm64), paquets publics — canal Staging :staging après CI verte sur main.
  
• Sur machine perso (Docker Desktop) : docker compose -f compose.yaml pull puis up -d --wait ouvre le Site sur https://localhost (joué ici avec ARGOS_VERSION=0.7.2, même digest que :staging au moment du test).
  
• À chaque Release vX.Y.Z, promouvoir le digest staging vers les étiquettes de version (X.Y.Z, :latest) — même digest, pas de rebuild ; les Sites prod suivent le semver.
  
• Installer un Site Ubuntu par installer-le-site.sh (docker compose pull) ; le Site répond en HTTPS.
  
  
• Mettre à jour au boot/restart de argos.service ou via mettre-a-jour-le-site.sh (artefact Release → /opt/argos, alignement ARGOS_VERSION, recreate ; codes 0 / 2 / 1).
  
• Lire le README (Hébergement Ubuntu + Essayer staging) : pull nominal, MAJ, secours save / load cohérents avec les scripts.
  
• Lire la procédure d'isolement VLAN (deux prises, caméras sans internet) — scénario de test humain 7 non rejoué sur cette passe (décision produit) ; voir #112.

Historique des tickets

• PR : #113
• Commits : https://github.com/UlyssouLV/ArgOS/pull/113/commits

Tickets (Fixes) : #107 #108 #109 #110 #111

Tests humains a posteriori : #112 (Closed)

Hors périmètre

Enregistrement des Flux (0.8.0) ; MAJ sans coupure ; timer quotidien ; rollback automatique ; hébergement Windows produit ; bugs #86 et #95 ; scanner Sonar dans Actions. Scénario VLAN des tests humains (#112 scénario 7) non joué (décision produit).

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.7.2/docs/specs/v0.7.2-livraison-continue.md

ADRs de cette version (liens sur ce tag, pas la base) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.7.2/docs/adr/0010-canaux-staging-et-production-par-retag.md

Issues laissées de côté (PR / spec hors périmètre) : #86 #95

V0.7.1 — Intégration continue

Pourquoi

Les tests (/t) et la stack Docker ne tournaient que sur la machine du développeur. Une PR pouvait être fusionnée dans main alors que la suite était rouge.

Ce qu’on peut faire maintenant

• Une PR vers main (y compris brouillon) lance le check ArgOS tests ; on voit le résultat sur la PR et dans Actions.
  
  
  
• main est protégé : tant que ArgOS tests n’est pas vert, la PR ne se fusionne pas (mergeable_state: blocked).
  
• La doc (README Développer + checks requis sur main) dit d’ajouter toute nouvelle CI à la liste des checks requis sur main.
• Un script du dépôt (scripts/lancer-les-tests.sh) rejoue le même travail hors Actions (stack Docker + racines test-roots).

Historique des tickets

• PR : #106
• Commits : https://github.com/UlyssouLV/ArgOS/pull/106/commits

Tickets (Fixes) : #102 #103 #104 #105

Hors périmètre

Publication des images au registre GitHub / livraison continue (0.7.2), scanner Sonar dans Actions, caches GitHub Actions, runners self-hosted, configuration automatique de la branch protection. Bugs #86 et #95.

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.7.1/docs/specs/v0.7.1-integration-continue.md

ADRs de cette version (liens sur ce tag, pas la base) :

• Aucun.

Issues laissées de côté (PR / spec hors périmètre) : #86 #95

V0.7.0 — Site installable sans le dépôt

Modifié en V0.7.2 (#107) — Transfert d'images Ubuntu
Avant : docker save / load nominal
Après : docker pull nominal ; save/load en secours

Modifié en V0.7.2 (#107) — Mise à jour Ubuntu
Avant : load + aligner ARGOS_VERSION + restart manuel
Après : MAJ au boot/restart + commande unique (semver Release, artefact, pull)

Modifié en V0.7.2 (#107) — Staging / production
Avant : Environnements Mac vs Ubuntu
Après : Canaux d'images :staging et Releases vX.Y.Z (promotion digest)

Pourquoi

On ne pouvait lancer un Site qu’en clonant le dépôt et en construisant les images depuis les sources. Un Administrateur ne pouvait pas poser ArgOS sur une machine Ubuntu comme un produit, ni relire deux procédures distinctes (Mac local vs Ubuntu).

Ce qu’on peut faire maintenant

• Construire les quatre images du Site (api, web, pont, certificats) étiquetées ghcr.io/ulyssoulv/argos-…:0.7.0. Sur un Mac Apple Silicon vers Ubuntu amd64, le build se fait avec DOCKER_DEFAULT_PLATFORM=linux/amd64.
  
• Les sauver (docker save des quatre images, sans Postgres) et les charger sur Ubuntu (docker load).
  
• Installer un Site dans /opt/argos sans les sources : compose, .env (sans Sonar), script de Détection, dossier certificats vide pour que Compose démarre.
  
• Relancer le Site avec systemd (argos.service) : restart, conteneur planté qui repart.
  
• Ouvrir https://<IP du Site>, se connecter en Administrateur, voir Administration et Live (pas de Caméras simulées en prod).
  
  
  
• Activer le réseau des caméras (macvlan) une fois en terminal, comme aujourd’hui.
  
• Mettre à jour en rechargeant les images et en relançant le service (scénario 8, sans capture).

Historique des tickets

• PR : #101
• Commits : https://github.com/UlyssouLV/ArgOS/pull/101/commits

Tickets (Fixes) : #96 #97 #98 #99 #100

Hors périmètre

CI des PR (0.7.1), publication au registre GitHub et promotion d’images déjà vertes (0.7.2), Windows, VPN / reverse proxy depuis internet, paquet .deb. Bugs #86 et #95.

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.7.0/docs/specs/v0.7.0-site-installable-sans-le-depot.md

ADRs de cette version (liens sur ce tag, pas la base) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.7.0/docs/adr/0009-images-du-depot-et-compose-autonome.md

V0.6.4 — Réglages image et vidéo par ONVIF

Modifié en V0.7.0 (#96) — Lancement
Avant : Clone obligatoire, build: seul
Après : Clone pour construire ; Site Ubuntu sans sources

Pourquoi

Depuis la 0.6.0, ArgOS règle par ONVIF les Incrustations et l'Horloge d'une Caméra. Le reste de ce qui fait une bonne image (filtre infrarouge, scène sombre, contre-jour, résolution ou débit trop lourds pour le réseau du Site) se réglait encore dans l'interface web du fabricant, souvent inutilisable, ou dans son application cloud. Et le média 1, le seul service qu'ArgOS parlait, décrit mal le H.265 : régler l'encodage par lui risquait de changer le codec du Flux.

Ce qu’on peut faire maintenant

• Voir le Flux de la Caméra en tête de ses Réglages, pour suivre l'effet d'un réglage sans quitter l'Administration.
  
• Régler l'Image de l'Appareil : filtre infrarouge (jour / nuit / automatique), luminosité, contraste, saturation, netteté, contre-jour et WDR. Chaque champ est relu avec un statut (« pris », « pas pris »), et l'Image vaut pour toutes les Caméras du même Appareil.
  
  
• Régler l'Encodage du Flux de la Caméra (résolution, images par seconde, débit max) dans les bornes de la caméra. Le codec, la qualité et l'intervalle entre images clés restent affichés seulement.
  
  
• Confirmer avant un changement d'Encodage, qui coupe le Flux quelques secondes. Une modification d'Image ou d'Incrustation seule part sans confirmation.
  
  
• Lire clairement ce qui ne se règle pas : « Image non réglable sur cette caméra », « Encodage non réglable sur cette caméra » (H.265 sans média 2), « Encodage introuvable pour ce Flux ».
  
  

Autres captures : image d'usine, Image non réglable, sans confirmation, Encodage introuvable, Live.

L'Encodage passe par le service média 2 quand la caméra l'annonce, par le média 1 seulement si le Flux est en H.264, sinon il reste en lecture seule. La Caméra du flux secondaire règle le flux secondaire : ArgOS retient le profil dont l'URL correspond à l'URL RTSP de la Caméra. Après un changement d'Encodage, ArgOS relit la caméra jusqu'à 20 s ; si elle ne répond pas, les champs envoyés sont « pas pris — la caméra n'a pas répondu après l'envoi ». Rien n'est gardé en base : la caméra reste la seule source de vérité.

Pour le développeur : la Caméra simulée 2 sert le service image et le média 2 (WDR accepté sans être appliqué, pour voir « pas pris »), la Caméra simulée 4 reste en média 1 seul, sans service image ; des options du simulateur coupent le média 2 (repli média 1 en H.264) ou rendent la caméra muette après un changement d'Encodage.

Historique des tickets

• PR : #94
• Commits : https://github.com/UlyssouLV/ArgOS/pull/94/commits

Tickets (Fixes) : #87 #88 #89 #90 #91 #92 #93

Hors périmètre

Exposition, balance des blancs, mise au point, stabilisation ; changer le codec, la qualité, l'intervalle entre images clés ou le mode de débit ; réseau, IP, utilisateurs et ports de la caméra (jamais) ; événements ONVIF, PTZ ; plusieurs sources vidéo par Appareil.

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.6.4/docs/specs/v0.6.4-reglages-image-et-video-par-onvif.md

ADRs de cette version (liens sur ce tag, pas main) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.6.4/docs/adr/0008-encodage-par-media-2-media-1-seulement-en-h264.md

Issues laissées de côté (PR / spec hors périmètre) : #86 #95

V0.6.3 — Sécurisation d'ONVIF

Modifié en V0.7.0 (#96) — Lancement
Avant : Clone obligatoire, build: seul
Après : Clone pour construire ; Site Ubuntu sans sources

Pourquoi

Depuis la 0.6.0, l’Administrateur règle une Caméra (Incrustations, Horloge) par ONVIF, mais ArgOS lui parlait en HTTP : qui écoutait le réseau des caméras capturait l’empreinte WS-Security du mot de passe (SHA-1, imposé par la norme, cassable hors ligne s’il est faible), lisait et modifiait les réglages au passage, et rien ne prouvait à ArgOS qu’il parlait à la bonne caméra. Avec l’authentification des Flux (0.6.2), c’était le dernier préalable à une installation sur de vraies caméras.

Ce qu’on peut faire maintenant

• Les Réglages d'une caméra qui propose HTTPS passent en HTTPS. ArgOS mémorise la clé de son certificat au premier contact et l'affiche (« Échange chiffré (HTTPS). Certificat de l'Appareil xxxx xxxx xxxx xxxx, mémorisé le … »), avec l'empreinte entière au survol. Rien n'est redemandé ensuite.

  

• Si la caméra présente une autre clé, ArgOS s'arrête avant d'envoyer ses identifiants. Il montre le certificat mémorisé et le certificat présenté, ainsi que les causes possibles. L'Administrateur tranche : Faire confiance au nouveau certificat, puis Confirmer la confiance.

  
  

• Une caméra déjà réglée en HTTPS qui ne répond plus qu'en HTTP n'est jamais réglée en clair. Oublier le certificat de cette caméra la fait repartir de zéro.

  

• Une caméra sans HTTPS n'est réglée en clair qu'après l'accord de l'Administrateur (Régler quand même en clair), une fois par Caméra. Un bandeau le rappelle ensuite, et Retirer l'accord ONVIF en clair revient en arrière.

  
  

• Clé, port et accord sont gardés quand on ne change que le mot de passe ou le chemin de l'URL. Ils repartent de zéro quand on change l'hôte.

• À l'ajout, un mot de passe de caméra de moins de 12 caractères est signalé sous les champs, sans bloquer l'ajout.

  

• Un refus de sécurité ne bloque que les Réglages de cette Caméra : le Live et l'état continuent.

  

• Chaque refus et chaque décision laisse une ligne dans les journaux de l'API (docker compose logs api | grep ONVIF), sans identifiant ni URL.

• Une caméra qui ne parle qu’un TLS ancien (1.0 / 1.1) reste réglée en HTTPS, signalée « TLS ancien » dans ses Réglages : un TLS faible avec une clé mémorisée vaut mieux que du clair.

• La Caméra simulée 2 répond désormais en ONVIF HTTPS sur 443 (HTTP gardé sur 8899) : on joue en dev le cas d’une caméra qui propose HTTPS ; la 4 reste en HTTP seul, pour l’ONVIF en clair.

• Les # NOSONAR laissés en 0.6.0 ne renvoient plus à cette version : il ne reste que des justifications définitives (repli HTTP consenti, SHA-1 de WS-Security, TLS ancien).

Historique des tickets

• PR : #85
• Commits : https://github.com/UlyssouLV/ArgOS/pull/85/commits

Tickets (Fixes) : #76 #77 #78 #79 #80 #81 #82 #83 #84

Hors périmètre

• Isolement du réseau des caméras (VLAN, sans internet), dans la procédure d’installation (0.7.2).
• Identifiants ONVIF distincts de ceux du Flux (Plus tard).
• RTSP vers les caméras (Flux, sonde, Détection, essai), qui reste en clair ; RTSPS.
• Passerelle chiffrante devant une caméra sans HTTPS.
• Recherche ONVIF par WS-Discovery ; réglages image et vidéo (0.6.4).
• Bug connu, trouvé aux tests humains : modifier l’URL d’une Caméra sans retaper son mot de passe enregistre *** comme mot de passe (#86, Plus tard).

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.6.3/docs/specs/v0.6.3-securisation-d-onvif.md

ADRs de cette version (liens sur ce tag, pas main) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.6.3/docs/adr/0007-onvif-en-https-par-cle-memorisee.md

Issues laissées de côté (PR / spec hors périmètre) : #86.

V0.6.2 — Authentification des Flux

Modifié en V0.7.0 (#96) — Lancement
Avant : Clone obligatoire, build: seul
Après : Clone pour construire ; Site Ubuntu sans sources

Pourquoi

Depuis la 0.6.1, l’UI, l’API et le Live passaient par une seule origine HTTPS et l’API exigeait une session, mais les Flux restaient en accès libre : nginx relayait WHEP (/flux/webrtc/…) et HLS (/flux/hls/…) vers MediaMTX sans demander de session, et RTSP 8554 était publié sur l’hôte, en clair et sans authentification. Avec de vraies caméras, le login d’ArgOS serait devenu décoratif : on aurait regardé n’importe quelle Caméra sans passer par la connexion.

Ce qu’on peut faire maintenant

• Regarder une Caméra demande d’être connecté à ArgOS : sans session, /flux/webrtc/… et /flux/hls/… répondent 401, même pour qui connaît le nom du chemin (camera-<id> comme apercu-<jeton>).
• Le RTSP du pont n’est plus ouvert au réseau du Site : rtsp://<IP du Site>:8554/… est refusé.
• Le Live (WebRTC pour le H.264, HLS pour le H.265) et l’Aperçu marchent comme avant une fois connecté.
• Si la session expire ou si on se déconnecte, l’écran du Live ou de l’Aperçu ramène à la connexion dès qu’un Flux est refusé, y compris dans Safari sur iPhone (HLS natif). Un Live WebRTC déjà ouvert continue jusqu’à la vidéo suivante : c’est une limite assumée.
• En dev, les Flux restent lisibles depuis sa machine (rtsp://127.0.0.1:8554/camera-<id>, VLC, ffprobe).
• La Détection trouve toujours les Caméras et ne liste ni ArgOS ni le pont.

Historique des tickets

• PR : #74
• Commits : https://github.com/UlyssouLV/ArgOS/pull/74/commits

Tickets (Fixes) : #69 #70 #71 #72 #73

Hors périmètre

• Couper un Live WebRTC déjà établi à la déconnexion ou à l’expiration de la session (Plus tard).
• Identifiant de lecture interne pour MediaMTX, et authentification de son API de contrôle 9997.
• Droits de lecture par Caméra (multi-compte).
• RTSP (ou RTSPS) authentifié pour un client externe (VLC, NVR).
• ONVIF en HTTPS (0.6.3).
• Images versionnées et compose de prod (0.7.0).

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.6.2/docs/specs/v0.6.2-authentification-des-flux.md

ADRs de cette version (liens sur ce tag, pas main) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.6.2/docs/adr/0006-flux-authentifies-par-nginx.md

Issues laissées de côté (PR / spec hors périmètre) : aucune.

V0.6.1 — HTTPS

Modifié en V0.7.0 (#96) — Lancement
Avant : Clone obligatoire, build: seul
Après : Clone pour construire ; Site Ubuntu sans sources

Modifié en V0.6.2 (#69) — Route /flux/ de nginx
Avant : relais vers MediaMTX sans session
Après : relais seulement après auth_request validé

Pourquoi

Jusqu’à la 0.6.0, l’UI, l’API et le Live étaient servis en HTTP sur quatre ports du Site : sur le Wi-Fi, le mot de passe de l’Administrateur, le cookie de session, les identifiants de caméra saisis à l’ajout et le jeton de l’Aperçu circulaient en clair. Le Site n’a pas de nom de domaine public, donc pas de certificat d’une autorité d’internet ; un certificat auto-signé aurait habitué l’Administrateur à ignorer les avertissements du navigateur.

Ce qu’on peut faire maintenant

• Ouvrir ArgOS en HTTPS, sous une seule adresse https://<IP du Site> : l’UI, l’API et le Live (WebRTC et HLS) passent par le nginx de web, sur le port 443 (réglable).
• Les anciennes adresses en clair (http://…:8080, http://<IP du Site>) redirigent vers la même page en HTTPS.
• Se connecter, administrer les Caméras (détection, ajout, Réglages ONVIF) et regarder le Live H.264 et H.265 comme avant.
• Les anciens ports de l’API et des Flux (8000, 8888, 8889) ne sont plus exposés sur le réseau ; le cookie de session porte Secure, et CORS a disparu.
• ArgOS crée seul, au premier lancement, l’Autorité du Site et le certificat du serveur, sans commande openssl. Son empreinte SHA-256 s’affiche au lancement.
• Depuis le Mac hôte, le lanceur propose d’ajouter l’Autorité du Site au trousseau, puis ouvre https://localhost sans avertissement ; aux lancements suivants, il ne redemande rien.
• Installer l’Autorité du Site sur un autre poste (macOS, iOS, Windows, Android) en la téléchargeant depuis http://<IP du Site>/argos-ca.crt, avec une doc pas à pas (« Installer l’Autorité du Site »).
• Quand l’IP du Site change ou que le certificat approche de l’expiration, un nouveau certificat serveur est créé et servi sans arrêter la stack, avec la même Autorité : rien à réinstaller sur les postes.
• Un Administrateur qui a son propre certificat (nom de domaine, VPN) peut le déposer à la place de celui d’ArgOS.
• Le schéma du réseau (conteneurs, ports, flux chiffrés ou en clair) rejoint la doc produit.

Historique des tickets

• PR : #67
• Commits : https://github.com/UlyssouLV/ArgOS/pull/67/commits

Tickets (Fixes) : #59 #60 #61 #62 #63 #64 #65 #66 #68

Hors périmètre

• Authentification des Flux MediaMTX : RTSP 8554 reste ouvert et en clair (0.6.2).
• HTTPS d’ArgOS vers les caméras, ONVIF encore en HTTP (0.6.3).
• HSTS.
• Sauvegarde ou export de l’Autorité du Site.
• Renouvellement automatique d’un certificat fourni par l’Administrateur (Let’s Encrypt, ACME).
• Images versionnées et compose de prod (0.7.0).

Spec : https://github.com/UlyssouLV/ArgOS/blob/v0.6.1/docs/specs/v0.6.1-https.md

ADRs de cette version (liens sur ce tag, pas main) :

• https://github.com/UlyssouLV/ArgOS/blob/v0.6.1/docs/adr/0005-https-par-une-origine-unique-et-une-autorite-du-site.md

Issues laissées de côté (PR / spec hors périmètre) : aucune.