Accès à distance : connexion et liste d'autorisation d'IP

Ce guide explique comment ouvrir Marinara Engine depuis un autre appareil : un téléphone, un ordinateur portable ou un conteneur Docker. Il couvre l'option principale, une connexion. Il couvre aussi la liste d'autorisation d'IP, les proxys de connexion, le HTTPS, la section Admin Access (accès administrateur) et le message CSRF "save blocked". Presque tous les réglages décrits ici se trouvent dans le fichier .env du serveur, pas dans l'application.

Un petit lexique utilisé tout au long de ce guide :

Se connecter de n'importe où avec Tailscale

Tailscale est un réseau privé pour tes propres appareils. Utilise-le pour ouvrir Marinara sur ton téléphone ou ton ordinateur portable, chez toi ou en déplacement, sans ouvrir de ports sur ton routeur ni mettre Marinara sur l'Internet public. Marinara fait confiance aux appareils qui se connectent directement via Tailscale : tu n'as donc pas besoin de définir de connexion.

  1. Installe Tailscale sur l'ordinateur qui exécute Marinara et sur ton autre appareil. Télécharge-le sur tailscale.com/download.
  2. Connecte-toi à Tailscale avec le même compte sur les deux appareils.
  3. Démarre Marinara avec start.sh, start.bat, start-termux.sh ou l'installateur Windows. Ces méthodes de lancement laissent les autres appareils se connecter. Si tu lances plutôt pnpm start, ajoute d'abord HOST=0.0.0.0 à ton fichier .env (voir Où se trouve le fichier .env).
  4. Trouve l'adresse Tailscale de l'ordinateur qui exécute Marinara. Ouvre l'application Tailscale sur cet ordinateur, ou lance tailscale ip -4. L'adresse commence par 100., par exemple 100.101.102.103.
  5. Sur ton autre appareil, active Tailscale et ouvre http://100.101.102.103:7860 dans un navigateur. Utilise ta propre adresse, et ton PORT si tu l'as changé. Marinara s'ouvre sans page de connexion.

Si la page ne se charge pas, vérifie que Tailscale est activé sur les deux appareils et que le serveur écoute sur HOST=0.0.0.0.

Remarque : cela ne fonctionne pas pour les installations Docker. Le trafic Tailscale atteint le conteneur par la passerelle Docker : Marinara ne peut donc pas voir qu'il vient de Tailscale. Définis d'abord une connexion (option 1), puis publie le port au-delà de 127.0.0.1.

Les sauvegardes, les imports, les mises à jour et les autres actions risquées exigent toujours le secret d'administration depuis un appareil distant. Voir Admin Access et actions privilégiées.

Ce que Marinara bloque par défaut

Pour protéger tes données, une installation neuve de Marinara refuse les connexions venant d'autres appareils tant que tu n'as pas mis en place un contrôle d'accès. Par défaut, seuls trois types de clients sont considérés comme fiables :

  1. Loopback (127.0.0.1 ou ::1), c'est-à-dire la machine qui exécute le serveur elle-même. Les visiteurs transmis par un reverse proxy ou un tunnel sur la même machine ne comptent pas ; voir Reverse proxies et tunnels sur le même ordinateur.
  2. Les appareils Tailscale de ton tailnet. Tailscale est un outil de réseau privé, et ses adresses utilisent la plage 100.64.0.0/10.
  3. Les clients Docker sur le même hôte. Marinara reconnaît la plage de pont habituelle 172.16.0.0/12 ainsi que la passerelle par défaut exacte du conteneur, ce qui couvre aussi Docker Desktop et les pools d'adresses personnalisés.

Tout le reste est bloqué tant que tu n'as pas défini de connexion : ton téléphone sur le même Wi-Fi, un client venant d'Internet, etc. Un appareil bloqué qui ouvre Marinara dans un navigateur tombe sur une page de configuration sombre. Son titre indique This Marinara Engine install needs a login before remote devices can connect. La page contient un formulaire pour le code de configuration à usage unique du log du serveur : tu peux ainsi définir la connexion depuis cet appareil.

Si tu ne fais rien et ne définis jamais de mot de passe, Marinara reste verrouillé sur ces trois sources fiables. C'est le comportement par défaut, et il est sûr.

Où se trouve le fichier .env

Tous les réglages d'accès se trouvent dans le fichier .env, à la racine du projet, à côté du fichier package.json. Si tu n'en as pas encore, copie l'exemple :

cp .env.example .env

Ouvre le fichier .env avec n'importe quel éditeur de texte. La plupart des réglages d'accès prennent effet en une poignée de secondes, sans redémarrage : Basic Auth, la liste d'autorisation d'IP, le secret d'administration et les origines CSRF. Quelques réglages de bas niveau demandent encore un redémarrage, dont la variable PORT, la variable HOST et les chemins des certificats HTTPS.

Il arrive que les autres appareils n'atteignent pas du tout le serveur : la connexion expire au lieu de renvoyer une erreur 403. Dans ce cas, le serveur n'écoute sans doute que sur la machine locale. Demande-lui d'écouter sur toutes les interfaces réseau :

HOST=0.0.0.0

Les lanceurs (start.bat, start.sh) définissent HOST=0.0.0.0 à ta place. Lancer directement la commande pnpm start ne le fait pas.

Adresse de liaison par défaut selon la façon dont tu lances Marinara :

Méthode de lancementValeur par défaut de HOST
pnpm start, start-local.bat127.0.0.1
start.sh, start.bat, installateur Windows, start-termux.sh0.0.0.0
Image Docker0.0.0.0 dans le conteneur
docker-compose.ymlPublie le port sur 127.0.0.1 uniquement

Quelle option choisir

Lis les cas suivants dans l'ordre et arrête-toi au premier qui te correspond.

  1. Tu te connectes uniquement en direct via Tailscale, ou uniquement depuis des conteneurs Docker sur le même hôte. Avec pnpm start, les clients Tailscale directs passent sans connexion ; définis HOST=0.0.0.0 pour qu'ils puissent joindre le serveur. Le fichier Compose par défaut publie uniquement sur 127.0.0.1. Si tu publies le port au-delà du loopback pour qu'un appareil Tailscale puisse le joindre, définis d'abord une connexion. Docker la demande alors à chaque appareil, appareils Tailscale compris, car Docker les voit à l'adresse de la passerelle. Voir Exception pour Tailscale et Docker.
  2. Tu veux ouvrir Marinara depuis un téléphone, une tablette ou un ordinateur portable, sur le Wi-Fi de la maison. Définis une connexion (option 1 ci-dessous).
  3. Tu exposes Marinara sur Internet. Définis une connexion et utilise le HTTPS.
  4. Un proxy de connexion de ton réseau, comme tinyauth, Authelia ou Authentik, fait déjà connecter chaque visiteur. Lis Proxys de connexion (forward auth).

Une connexion est le choix le plus souple. Elle fonctionne depuis n'importe quelle IP, ne demande aucune configuration sur chaque appareil, et chaque navigateur reste connecté.

Option 1 : Connexion (recommandée)

Une connexion est un nom d'utilisateur et un mot de passe que chaque appareil distant doit fournir. Tu peux la définir de trois façons :

BASIC_AUTH_USER=alice
BASIC_AUTH_PASS=correct-horse-battery-staple

Une connexion dans .env l'emporte sur une connexion définie dans l'application, et tu ne la modifies que dans .env. Enregistre .env ; la modification prend effet en quelques secondes, sans redémarrage.

Choisis un mot de passe solide et unique. L'application demande au moins 10 caractères. Tu peux en générer un au hasard :

openssl rand -base64 24

Ensuite, procède ainsi depuis l'appareil distant.

  1. Ouvre Marinara dans le navigateur avec l'adresse du serveur, par exemple http://192.168.1.50:7860.
  2. Connecte-toi sur la page de connexion avec ton nom d'utilisateur et ton mot de passe.
  3. L'application doit se charger. Le navigateur reste connecté jusqu'à un an, jusqu'à ce que tu te déconnectes. Les scripts et les clients d'API envoient le nom d'utilisateur et le mot de passe à chaque requête (Basic Auth).

Pour connecter un autre appareil sans retaper le mot de passe, utilise un code d'appairage. Sur un appareil déjà connecté, ouvre Settings → Advanced → Access et choisis Add a device (ajouter un appareil). Saisis ensuite le code sur la page de connexion du nouvel appareil. Le code ne fonctionne qu'une fois, pendant quelques minutes. Un code expiré reçoit son propre message ; il faut en créer un nouveau. Sous Signed-in devices (appareils connectés), tu vois chaque appareil avec sa méthode de connexion et la date de sa première connexion. Tu peux déconnecter n'importe quel appareil, y compris celui que tu utilises. Tu peux aussi modifier ou supprimer le mot de passe. Pour cela, Marinara demande le mot de passe actuel, sauf si tu travailles sur l'ordinateur qui fait tourner Marinara ou si ADMIN_SECRET est défini.

Si tu oublies le mot de passe, lance node scripts/reset-login.mjs dans le dossier de Marinara, sur l'ordinateur qui fait tourner Marinara. Dans Docker, lance docker exec <container> node scripts/reset-login.mjs. Cette commande supprime la connexion définie dans l'application et déconnecte chaque navigateur. Si le serveur écoute au-delà du loopback, elle affiche ensuite un nouveau code de configuration. Seulement si cette commande ne fonctionne pas, supprime plutôt .remote-login.json et .remote-sessions.json du dossier de données. Avec le /app/data par défaut, lance docker exec <container> rm -f /app/data/.remote-login.json /app/data/.remote-sessions.json ; si tu as changé DATA_DIR, utilise ce dossier. Une connexion dans .env se modifie dans .env.

Serveur sans interface et sans navigateur ? Une installation native sur un serveur sans interface écoute uniquement sur le loopback et n'affiche aucun code de configuration. Sur ton propre ordinateur, lance ssh -L 7860:127.0.0.1:7860 user@server. Ouvre ensuite http://localhost:7860 et utilise Settings.

Après 10 mots de passe ou codes erronés différents en 15 minutes, Marinara refuse les tentatives de connexion depuis cette adresse avec 429 Too Many Requests, jusqu'à la fin de ces 15 minutes. Un mot de passe correct saisi avant remet le compteur à zéro. Les visiteurs transmis par un reverse proxy ou un tunnel sur l'hôte partagent un seul compteur, et la connexion de l'un d'eux ne le remet pas à zéro. Redémarrer le serveur le remet aussi à zéro. Un navigateur déjà connecté entre toujours avec le bon mot de passe : les mots de passe erronés d'autres personnes ne peuvent donc pas te bloquer l'accès depuis un appareil que tu utilises déjà. La page de connexion indique combien de minutes attendre. Si tu oublies le mot de passe, la page de connexion affiche un indice Forgot the password?.

Les navigateurs se connectent sur la page /login. BASIC_AUTH_REALM change le realm du défi Basic Auth pour les scripts et les clients d'API ; il ne change pas la page de connexion.

Certains clients passent outre le mot de passe, même quand Basic Auth est activé :

Important : Basic Auth se contente d'encoder le mot de passe, il ne le chiffre pas. N'importe qui surveillant une connexion non chiffrée peut le lire. Si tu exposes Marinara sur Internet, associe Basic Auth au HTTPS (voir plus bas).

Option 2 : liste d'autorisation d'IP

La liste d'autorisation d'IP laisse entrer certaines adresses sans mot de passe. Elle convient bien quand tes appareils ont des adresses IP stables. Indique une liste d'adresses ou de plages, séparées par des virgules :

IP_ALLOWLIST=192.168.1.0/24,203.0.113.42

Le /24 de l'exemple, c'est de la notation CIDR. Le CIDR est une façon courte d'écrire toute une plage d'adresses en une seule entrée. Par exemple, 192.168.1.0/24 couvre toutes les adresses de 192.168.1.0 à 192.168.1.255. Une adresse seule, sans barre oblique, comme 203.0.113.42, ne correspond qu'à cet appareil-là.

Une large plage publique, comme 0.0.0.0/0, peut laisser entrer des clients d'internet sans connexion. N'indique que des adresses de confiance.

Comment se comporte la liste d'autorisation d'IP :

La liste d'autorisation ne permet pas un montage mixte, où les appareils listés éviteraient le mot de passe pendant que tous les autres s'identifient. Si tu veux que les autres appareils s'identifient avec un mot de passe, laisse la variable IP_ALLOWLIST vide et utilise Basic Auth seul.

L'application de la liste se désactive un moment, sans supprimer la liste elle-même. C'est pratique quand tu cherches un problème depuis une nouvelle IP. Mets l'indicateur d'activation à false :

IP_ALLOWLIST_ENABLED=false

Contournement du réseau privé (référence)

Quelques indicateurs suppriment le verrouillage pour un réseau privé de confiance. Ils sont réservés à des configurations particulières. Une connexion est le meilleur choix. Voir Contrôle d'accès pour les indicateurs et leurs risques.

Contournement Tailscale et Docker

Par défaut, Marinara fait confiance à un appareil qui se connecte directement à ton réseau Tailscale. Il fait aussi confiance à l'hôte propre d'un conteneur Docker. Une connexion, une liste d'autorisation d'IP ou TRUSTED_AUTH_PROXY arrête la confiance automatique envers Docker : chaque appareil a alors besoin de sa connexion ou de sa place dans la liste d'autorisation. Pour les indicateurs qui changent cela, voir Contrôle d'accès.

Docker Desktop, OrbStack et Docker sans root (rootless) font apparaître chaque appareil qui utilise un port publié à l'adresse de la passerelle Docker. Si tu publies le port sur toutes les interfaces (-p 7860:7860) et que tu ne définis aucune connexion, n'importe qui sur ton réseau peut entrer. Garde le port sur 127.0.0.1 ou définis d'abord une connexion. Le journal du serveur avertit de ce risque au démarrage.

Reverse proxies et tunnels sur le même ordinateur

Un reverse proxy ou un tunnel installé sur la machine qui exécute Marinara, comme nginx, Caddy, Traefik, Cloudflare Tunnel, Tailscale Serve ou Funnel, ou ngrok, se connecte à Marinara depuis loopback. Marinara le reconnaît grâce aux en-têtes de transmission que le proxy ajoute : Forwarded, X-Forwarded-For, X-Real-IP, X-Forwarded-Host, X-Forwarded-Proto, CF-Connecting-IP, True-Client-IP, les en-têtes d'identité Tailscale ou Via. Marinara reconnaît aussi une requête qui arrive en HTTP/1.0, car les navigateurs ne l'utilisent jamais, mais un proxy_pass nginx par défaut si. Marinara reconnaît aussi une requête dont l'en-tête Host désigne un autre ordinateur, comme un domaine ou une adresse du réseau local, même lorsque le proxy n'ajoute aucun en-tête. Il traite alors chaque requête comme le visiteur distant qu'elle représente :

Ton propre navigateur sur cette machine, ouvert sur http://127.0.0.1:7860 ou http://localhost:7860, reste sans mot de passe.

Caddy, Traefik, Cloudflare Tunnel, Tailscale et ngrok ajoutent des en-têtes de transmission par défaut. Pour nginx, cette ligne reste recommandée dans le bloc location :

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Les outils qui transmettent des connexions brutes, comme socat ou ssh -R, n'ajoutent aucun en-tête : leur trafic paraît donc local. Ne les utilise pas pour publier Marinara.

Si ton proxy oblige déjà chaque visiteur à se connecter avant de transmettre quoi que ce soit, lis Proxys de connexion (forward auth).

Proxys de connexion (forward auth)

Un proxy d'authentification préalable (forward auth), comme tinyauth, Authelia, Authentik ou oauth2-proxy, demande à chaque visiteur de se connecter avant de transmettre la requête. Si un tel proxy est le seul moyen d'atteindre Marinara, tu peux ignorer la seconde connexion de Marinara. Ne définis pas cela sans un tel proxy.

Mets l'adresse du proxy dans .env :

TRUSTED_AUTH_PROXY=192.168.1.5

Marinara laisse alors passer chaque requête dont la connexion provient de cette adresse. Marinara ne demande pas sa propre connexion pour elles, et il n'affiche aucun code de configuration. Marinara vérifie l'adresse de la connexion elle-même. Il ignore pour cela les en-têtes de transmission comme X-Forwarded-For. Les requêtes du proxy passent aussi IP_ALLOWLIST, car le proxy décide qui entre. Elles ne comptent pas comme locales : les actions privilégiées demandent donc toujours le secret d'administration. Settings → Advanced → Access affiche Trusted login proxy: Set tant que le réglage est actif.

Avant de le définir :

Quand TRUSTED_AUTH_PROXY est défini, Marinara arrête aussi la confiance automatique envers Docker. Les visiteurs directs qui ne sont pas le proxy ont besoin de la connexion de Marinara ou de la liste d'autorisation d'IP. Marinara n'affiche alors plus non plus la bannière "no login yet".

Si le proxy tourne sur le même ordinateur que Marinara, utilise TRUSTED_AUTH_PROXY=127.0.0.1 et dirige le proxy vers 127.0.0.1:7860, pas vers localhost:7860. Un proxy qui appelle localhost peut se connecter depuis ::1, qui ne correspond pas à 127.0.0.1. Tous les autres proxys ou tunnels de cet ordinateur sont alors aussi considérés de confiance : utilise donc ce réglage uniquement si le proxy de connexion est le seul. Cela ne donne pas aux visiteurs passant par le proxy l'accès de la machine locale.

Un exemple Caddy, avec Marinara sur 192.168.1.20:7860 :

marinara.example.com {
  forward_auth tinyauth:3000 {
    uri /api/auth/caddy
  }
  reverse_proxy 192.168.1.20:7860
}

Pour Authelia, utilise forward_auth authelia:9091 avec uri /api/authz/forward-auth. Authentik sert aussi ses propres pages de connexion via le proxy. Mets ses lignes dans un bloc route pour que Caddy conserve leur ordre et que le chemin outpost ne passe pas lui-même par forward auth :

marinara.example.com {
  route {
    reverse_proxy /outpost.goauthentik.io/* authentik-server:9000
    forward_auth authentik-server:9000 {
      uri /outpost.goauthentik.io/auth/caddy
    }
    reverse_proxy 192.168.1.20:7860
  }
}

Pour Traefik et nginx, suis le guide forward-auth de ton proxy. Marinara n'a besoin de rien de plus que l'adresse du proxy.

Servir Marinara en HTTPS

Le HTTPS chiffre la connexion grâce au TLS. Le TLS est le chiffrement qui transforme une adresse http ordinaire en adresse https sécurisée. Utilise toujours le HTTPS pour une installation joignable en dehors d'un réseau privé entièrement de confiance, surtout avec Basic Auth.

Deux façons de le mettre en place.

  1. Le TLS intégré. Indique au serveur un fichier de certificat et un fichier de clé privée :
SSL_CERT=/path/to/cert.pem
SSL_KEY=/path/to/key.pem
  1. Le reverse proxy. Place Marinara derrière nginx, Caddy, Traefik ou un Cloudflare Tunnel. Le proxy s'occupe de la partie HTTPS et transmet à Marinara en HTTP simple, sur la même machine. Lis d'abord Reverse proxies et tunnels sur le même ordinateur.

Il te faut un certificat et une clé avant de définir les variables SSL_CERT et SSL_KEY. Un outil comme mkcert en crée un pour un usage local, certbot pour un domaine public. Si les fichiers manquent ou sont illisibles, le serveur s'arrête au démarrage et indique les chemins exacts qu'il a essayés.

Admin Access et actions privilégiées

Certaines actions sont particulièrement sensibles : effacer les données, créer ou télécharger des sauvegardes, importer et exporter des profils, installer des thèmes et des agents, et installer le runtime Local Model. Elles exigent un secret partagé à part, appelé le secret d'administration, en plus de l'option d'accès que tu as choisie plus haut.

Sur la machine loopback, ces actions fonctionnent en général sans secret d'administration. Depuis un appareil distant, il faut d'abord le configurer. Tu peux le créer dans l'application ou le définir dans .env.

Les agents installés, comme ceux de l'écran d'accueil, n'ont pas besoin du secret d'administration. Un appareil qui s'est connecté avec la connexion peut s'en servir. Installer, mettre à jour et supprimer un agent l'exigent toujours.

Créer le secret d'administration dans l'application

  1. Sur l'ordinateur qui fait tourner Marinara, ouvre Settings, puis l'onglet Advanced, puis la section Admin Access.
  2. Clique sur Make admin secret (créer un secret d'administration). Marinara affiche le nouveau secret une seule fois et l'enregistre dans ce navigateur.
  3. Sur chaque appareil distant, ouvre Settings → Advanced → Admin Access, saisis le secret dans le champ, puis clique sur Save. Les majuscules, les espaces et les tirets n'ont pas d'importance.

Un appareil qui a déjà le secret peut aussi le créer. Un appareil seulement connecté avec la connexion ne le peut pas. Cela empêche qu'une connexion volée prenne le contrôle des actions risquées.

Avec Docker, ton navigateur atteint Marinara par le réseau Docker : Marinara ne le considère donc pas comme le même ordinateur. Définis plutôt le premier secret dans .env (voir plus bas).

Pour changer le secret, clique sur Replace admin secret (remplacer le secret d'administration). L'ancien secret cesse de fonctionner sur tous les appareils. Pour le désactiver, clique sur Remove admin secret (supprimer le secret d'administration). Marinara ne garde qu'une empreinte du secret, dans le fichier .admin-secret.json du dossier de données. Supprimer ce fichier supprime aussi le secret.

Définir le secret d'administration dans .env

  1. Dans le fichier .env, définis une valeur aléatoire solide, puis enregistre. Elle prend effet en une poignée de secondes, sans redémarrage.
ADMIN_SECRET=some-long-random-string
  1. Sur l'appareil distant, ouvre Settings → Advanced → Admin Access.
  2. Colle la même valeur dans le champ (son texte indicatif affiche ADMIN_SECRET), puis clique sur Save.
  3. Le message Admin secret saved for this browser doit apparaître.

ADMIN_SECRET dans .env l'emporte sur un secret créé dans l'application. Tant qu'il est défini, Admin Access l'indique, et tu ne changes le secret que dans .env.

Bon à savoir

Si une action privilégiée échoue sur un appareil distant, Marinara affiche un message d'erreur avec deux solutions. La première : ouvrir l'application via localhost. La seconde : configurer le secret d'administration comme décrit plus haut.

Pourquoi mon enregistrement est-il bloqué (CSRF)

CSRF veut dire cross-site request forgery, la falsification de requête entre sites. Cette protection empêche un autre site ouvert dans ton navigateur de modifier discrètement des choses dans Marinara sans ta permission. Elle fonctionne toute seule. Aucun réglage ne sert à l'activer.

Il arrive que la protection CSRF bloque tes propres enregistrements. En général, c'est parce que tu atteins Marinara via un nom de domaine public ou un port inhabituel auquel le serveur ne fait pas encore confiance. Deux signes te préviennent quand ça arrive.

Pour corriger ça, ajoute ton adresse à la liste de confiance dans le fichier .env :

CSRF_TRUSTED_ORIGINS=https://chat.example.com,http://203.0.113.10:7831

Avec un domaine public ou un domaine de reverse proxy, autorise aussi le nom d'hôte :

TRUSTED_HOSTS=chat.example.com

Les adresses LAN directes, Tailscale, IPv4 et IPv6 n'ont pas besoin de la variable TRUSTED_HOSTS. Les noms locaux en .local/.home.arpa et les noms de machine en un seul mot sont acceptés automatiquement. Un nom d'hôte exact déjà présent dans CSRF_TRUSTED_ORIGINS est accepté lui aussi.

Les origines loopback, les adresses LAN classiques, Tailscale (100.64.0.0/10) et le pont Docker (172.16.0.0/12) sont de confiance automatiquement. Tu n'as à lister que les adresses IP publiques et les noms de domaine. La modification prend effet en une poignée de secondes, sans redémarrage.

Une note sur les fournisseurs locaux bloqués

Imagine que tu connectes Marinara à un fournisseur d'IA local, par exemple un fournisseur qui tourne sur ta propre machine. La requête peut être refusée avec un message parlant de "private, loopback, metadata, or reserved IP range". Il s'agit d'un autre contrôle de sécurité, la protection SSRF. SSRF veut dire server-side request forgery, la falsification de requête côté serveur. Elle empêche le serveur d'appeler des adresses privées, sauf si tu l'y autorises. L'erreur nomme la variable .env exacte à définir, par exemple PROVIDER_LOCAL_URLS_ENABLED. La référence de configuration du serveur en donne la liste complète.

Accès depuis un téléphone ou une tablette

Pour ouvrir Marinara depuis un téléphone ou une tablette sur le même réseau :

  1. Vérifie que le serveur écoute sur toutes les interfaces, avec HOST=0.0.0.0 dans le fichier .env.
  2. Définis une connexion (option 1 ci-dessus). Depuis le téléphone, tu peux le faire sur la page qui te bloque, avec le code de configuration du log du serveur.
  3. Trouve l'adresse IP locale de la machine qui exécute le serveur (par exemple 192.168.1.50).
  4. Sur le téléphone, ouvre http://192.168.1.50:7860 dans un navigateur. Le port par défaut est 7860.
  5. Connecte-toi avec ton nom d'utilisateur et ton mot de passe.

Si la page ne se charge pas du tout, le serveur n'est sans doute pas joignable. Vérifie HOST=0.0.0.0 et la valeur de la variable PORT. Si tu obtiens plutôt une erreur 403, ton appareil joint bien le serveur mais n'y est pas encore autorisé. Reprends l'option que tu as choisie plus haut.

Verrouillé après une mise à jour

Les versions récentes demandent une connexion lorsqu'une visite passe par un reverse proxy, un tunnel, Tailscale Serve ou Tailscale Funnel. Les anciennes versions laissaient entrer ces visites sans mot de passe. Si tu vois maintenant une page de connexion, une page de configuration ou un 403, c'est la raison.

Note de mise à jour : si tu utilises Tailscale Serve, ou un autre proxy sur le même ordinateur, et que tu n'as jamais défini de mot de passe, tes autres appareils sont verrouillés après la mise à jour. Un proxy sur le même ordinateur parle en général à un serveur qui écoute uniquement sur loopback ; le serveur n'affiche donc aucun code de configuration. Définis plutôt la connexion sur l'ordinateur qui exécute Marinara.

Pour revenir :

  1. Ouvre Marinara sur l'ordinateur qui l'exécute, à l'adresse http://localhost:7860 (ou ton propre PORT). L'usage local ne demande pas de mot de passe. Sur un serveur sans interface, lance d'abord ssh -L 7860:127.0.0.1:7860 user@server sur ton propre ordinateur, puis ouvre http://localhost:7860. Dans Docker, cela ne fonctionne que tant qu'aucune connexion ni IP_ALLOWLIST n'est définie. Sinon, saisis le code de configuration du log du serveur (docker logs <container> 2>&1 | grep "setup code") sur la page qui te bloque ou dans Settings → Advanced → Access, ou utilise un navigateur déjà connecté.
  2. Va dans Settings → Advanced → Access et définis un nom d'utilisateur et un mot de passe sous Remote login. Ou ouvre le fichier .env sur cet ordinateur et définis BASIC_AUTH_USER et BASIC_AUTH_PASS. Si IP_ALLOWLIST est définie, ajoute-y l'adresse de ton autre appareil ou supprime-la, car un appareil absent de la liste reçoit un 403 même avec une connexion.
  3. Connecte-toi depuis ton autre appareil avec ce nom d'utilisateur et ce mot de passe.

Moteurs de recherche

Marinara demande aux moteurs de recherche de ne pas indexer ses pages (X-Robots-Tag: noindex, nofollow). Cela ne protège pas ton installation et ne supprime pas les pages déjà indexées. Utilise les contrôles d'accès ci-dessus pour garder ton installation privée.

Guides associés