Acceso remoto: inicio de sesión y lista de IP permitidas

Esta guía explica cómo llegar a Marinara Engine desde otro dispositivo, como tu teléfono, una laptop o un contenedor de Docker. Cubre la opción principal: un inicio de sesión. También cubre la lista de IP permitidas, los proxies de inicio de sesión, HTTPS, Admin Access y el mensaje CSRF de "save blocked" (guardado bloqueado). Casi todos los ajustes de aquí viven en el archivo .env del servidor, no en la app.

Una lista rápida de palabras que se usan en toda esta guía:

Conectarse desde cualquier lugar con Tailscale

Tailscale es una red privada para tus propios dispositivos. Úsala para abrir Marinara en tu teléfono o tu laptop, en casa o fuera de ella, sin abrir puertos en tu router ni poner Marinara en el internet público. Marinara confía en los dispositivos que se conectan directamente por Tailscale, así que no necesitas configurar un inicio de sesión.

  1. Instala Tailscale en la computadora que ejecuta Marinara y en tu otro dispositivo. Descárgalo desde tailscale.com/download.
  2. Inicia sesión en Tailscale con la misma cuenta en ambos dispositivos.
  3. Inicia Marinara con start.sh, start.bat, start-termux.sh o el instalador de Windows. Estos permiten que otros dispositivos se conecten. Si en cambio ejecutas pnpm start, añade primero HOST=0.0.0.0 a tu archivo .env (consulta Dónde vive el archivo .env).
  4. Busca la dirección de Tailscale de la computadora de Marinara. Abre la app de Tailscale en ella, o ejecuta tailscale ip -4. La dirección empieza por 100., por ejemplo 100.101.102.103.
  5. En tu otro dispositivo, activa Tailscale y abre http://100.101.102.103:7860 en un navegador. Usa tu propia dirección, y tu PORT si lo cambiaste. Marinara se abre sin página de inicio de sesión.

Si la página no carga, revisa que Tailscale esté activado en ambos dispositivos y que el servidor escuche en HOST=0.0.0.0.

Nota: Esto no funciona en las instalaciones de Docker. El tráfico de Tailscale llega al contenedor a través de la puerta de enlace de Docker, así que Marinara no puede ver que vino de Tailscale. Configura primero un inicio de sesión (Opción 1) y luego publica el puerto más allá de 127.0.0.1.

Las copias de seguridad, las importaciones, las actualizaciones y otras acciones de riesgo siguen necesitando el secreto de admin desde un dispositivo remoto. Consulta Admin Access y acciones privilegiadas.

Lo que Marinara bloquea de forma predeterminada

Para proteger tus datos, una instalación nueva de Marinara rechaza las conexiones de otros dispositivos hasta que configuras el control de acceso. De forma predeterminada, solo se confía en tres tipos de cliente:

  1. Loopback (127.0.0.1 o ::1), la máquina que ejecuta el servidor. Los visitantes que reenvía un proxy inverso o un túnel en la misma máquina no cuentan; consulta Proxies inversos y túneles en la misma computadora.
  2. Dispositivos de Tailscale en tu tailnet. Tailscale es una herramienta de red privada, y sus direcciones usan el rango 100.64.0.0/10.
  3. Clientes de Docker en el mismo host. Marinara reconoce el rango de puente habitual 172.16.0.0/12 y la puerta de enlace predeterminada exacta del contenedor, lo que también cubre Docker Desktop y los grupos de direcciones personalizados.

Todo lo demás, como tu teléfono en la misma Wi-Fi o un cliente de internet público, queda bloqueado hasta que configures un inicio de sesión. Un dispositivo bloqueado que abre Marinara en un navegador ve una página de configuración oscura. Su título dice This Marinara Engine install needs a login before remote devices can connect. (Esta instalación de Marinara Engine necesita un inicio de sesión antes de que los dispositivos remotos puedan conectarse.) La página tiene un formulario para el código de configuración de un solo uso del registro del servidor, así que puedes configurar el inicio de sesión desde ese dispositivo.

Si no haces nada y nunca configuras una contraseña, Marinara sigue bloqueada a esas tres fuentes de confianza. Ese es el valor predeterminado seguro.

Dónde vive el archivo .env

Todos los ajustes de acceso viven en tu archivo .env en la raíz del proyecto, junto a package.json. Si aún no tienes uno, copia el ejemplo:

cp .env.example .env

Abre .env con cualquier editor de texto. La mayoría de los ajustes de acceso, incluidos Basic Auth, la lista de IP permitidas, el secreto de admin y los orígenes CSRF, se aplican en un par de segundos sin reiniciar. Unos pocos ajustes de bajo nivel todavía necesitan reinicio, incluidos PORT, HOST y las rutas del certificado HTTPS.

Puede que otros dispositivos no logren llegar al servidor en absoluto, con un tiempo de espera en lugar de un 403. En ese caso, es posible que el servidor solo esté escuchando en la máquina local. Configura el servidor para que escuche en todas las interfaces de red:

HOST=0.0.0.0

Los lanzadores de shell (start.bat, start.sh) configuran HOST=0.0.0.0 por ti. Ejecutar pnpm start directamente no lo hace.

Dirección de vinculación predeterminada según cómo inicies Marinara:

Forma de inicioHOST predeterminado
pnpm start, start-local.bat127.0.0.1
start.sh, start.bat, instalador de Windows, start-termux.sh0.0.0.0
Imagen de Docker0.0.0.0 dentro del contenedor
docker-compose.ymlPublica el puerto solo en 127.0.0.1

Qué opción deberías elegir

Léelas en orden y detente en la primera que coincida contigo.

  1. Solo te conectas directamente por Tailscale, o solo desde contenedores de Docker en el mismo host. Con pnpm start, los clientes directos de Tailscale se saltan el inicio de sesión; define HOST=0.0.0.0 para que puedan llegar al servidor. El archivo Compose predeterminado publica solo en 127.0.0.1. Si publicas el puerto más allá del loopback para que un dispositivo Tailscale pueda llegar, define primero un inicio de sesión. Docker entonces lo pide a todos los dispositivos, incluidos los de Tailscale, porque Docker los ve en la dirección de la puerta de enlace. Consulta Bypass de Tailscale y Docker.
  2. Quieres llegar a Marinara desde un teléfono, una tableta o una laptop en la Wi-Fi de tu casa. Configura un inicio de sesión (Opción 1, abajo).
  3. Estás exponiendo Marinara al internet público. Configura un inicio de sesión y usa HTTPS.
  4. Un proxy de inicio de sesión en tu red, como tinyauth, Authelia o Authentik, ya hace iniciar sesión a cada visitante. Lee Proxies de inicio de sesión (forward auth).

Un inicio de sesión es la opción más flexible. Funciona desde cualquier IP, no necesita configuración por dispositivo, y cada navegador sigue con la sesión iniciada.

Opción 1: inicio de sesión (recomendado)

Un inicio de sesión es un nombre de usuario y una contraseña que necesita cada dispositivo remoto. Puedes configurarlo de tres maneras:

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

Un inicio de sesión en .env tiene prioridad sobre uno configurado en la app, y lo cambias solo en .env. Guarda .env; el cambio se aplica en un par de segundos, sin reiniciar.

Elige una contraseña fuerte y única. La app pide al menos 10 caracteres. Puedes generar una al azar:

openssl rand -base64 24

Luego sigue estos pasos desde el dispositivo remoto.

  1. Abre Marinara en tu navegador usando la dirección del servidor, por ejemplo http://192.168.1.50:7860.
  2. Inicia sesión en la página de inicio de sesión con tu nombre de usuario y tu contraseña.
  3. Deberías ver la app cargarse. El navegador mantiene la sesión iniciada hasta por un año, hasta que cierres sesión. Los scripts y los clientes de API envían el nombre de usuario y la contraseña con cada solicitud (Basic Auth).

Para iniciar sesión en otro dispositivo sin escribir la contraseña, usa un código de emparejamiento. En un dispositivo que ya haya iniciado sesión, abre Settings → Advanced → Access y elige Add a device. Luego escribe el código en la página de inicio de sesión del dispositivo nuevo. El código funciona una vez, durante unos minutos. Un código vencido recibe su propio mensaje; crea uno nuevo. En Signed-in devices ves cada dispositivo con su método de inicio de sesión y la fecha en que inició sesión por primera vez. Puedes cerrar la sesión de cualquier dispositivo, incluido el que usas. También puedes cambiar o quitar la contraseña. Para eso, Marinara pide la contraseña actual, salvo que trabajes en la computadora que ejecuta Marinara o hayas configurado ADMIN_SECRET.

Si olvidas la contraseña, ejecuta node scripts/reset-login.mjs en la carpeta de Marinara de la computadora que ejecuta Marinara. En Docker, ejecuta docker exec <container> node scripts/reset-login.mjs. Elimina el inicio de sesión configurado en la app y cierra la sesión en todos los navegadores. Si el servidor escucha más allá de loopback, imprime entonces un código de configuración nuevo. Solo si ese comando no funciona, elimina .remote-login.json y .remote-sessions.json de la carpeta de datos. Con el valor predeterminado /app/data, ejecuta docker exec <container> rm -f /app/data/.remote-login.json /app/data/.remote-sessions.json; si cambiaste DATA_DIR, usa esa carpeta. Un inicio de sesión en .env lo cambias en .env.

¿Servidor sin pantalla y sin navegador? Una instalación nativa en un servidor sin pantalla escucha solo en loopback y no imprime ningún código de configuración. En tu propia computadora, ejecuta ssh -L 7860:127.0.0.1:7860 user@server. Luego abre http://localhost:7860 allí y usa Settings.

Tras 10 contraseñas o códigos incorrectos distintos en 15 minutos, Marinara rechaza los inicios de sesión desde esa dirección con 429 Too Many Requests (429 Demasiadas solicitudes) hasta que pasan los 15 minutos. Una contraseña correcta antes de ese momento borra el recuento. Los visitantes con un proxy inverso o un túnel en el host que reenvía comparten un recuento, y que uno de ellos inicie sesión no lo borra. Reiniciar el servidor también lo borra. Un navegador que ya inició sesión antes sigue entrando con la contraseña correcta, así que las contraseñas incorrectas de otras personas no pueden bloquearte el acceso desde un dispositivo que ya usas. La página de inicio de sesión te dice cuántos minutos esperar. Si olvidas la contraseña, la página de inicio de sesión tiene una pista Forgot the password? (¿Olvidaste la contraseña?).

Los navegadores inician sesión en la página /login. BASIC_AUTH_REALM cambia el realm del desafío de Basic Auth para scripts y clientes de API; no cambia la página de inicio de sesión.

Algunos clientes se saltan la contraseña incluso con un inicio de sesión activado:

Importante: Basic Auth solo codifica la contraseña. No la cifra. Cualquiera que observe una conexión sin cifrar puede leerla. Si expones Marinara al internet público, combina Basic Auth con HTTPS (ver abajo).

Opción 2: lista de IP permitidas

La lista de IP permitidas deja entrar direcciones específicas sin contraseña. Encaja bien cuando tus dispositivos tienen direcciones IP estables. Configura una lista de direcciones o rangos separados por comas:

IP_ALLOWLIST=192.168.1.0/24,203.0.113.42

El /24 del ejemplo es notación CIDR. CIDR es una forma corta de escribir todo un rango de direcciones en una sola entrada. Por ejemplo, 192.168.1.0/24 cubre todas las direcciones desde 192.168.1.0 hasta 192.168.1.255. Una dirección sola, sin barra, como 203.0.113.42, coincide solo con ese dispositivo.

Un rango público amplio, como 0.0.0.0/0, puede dejar entrar a clientes de internet sin iniciar sesión. Incluye solo direcciones de confianza.

Cómo se comporta la lista de IP permitidas:

La lista permitida no puede crear una configuración mixta en la que los dispositivos de la lista se salten la contraseña y todos los demás inicien sesión. Si quieres que otros dispositivos inicien sesión con una contraseña, deja IP_ALLOWLIST sin configurar y usa Basic Auth solo.

Puedes desactivar la aplicación de la regla por un rato sin borrar tu lista. Esto es útil al resolver problemas desde una IP nueva. Configura el indicador de activación en falso:

IP_ALLOWLIST_ENABLED=false

Bypass de red privada (referencia)

Algunos indicadores quitan el bloqueo para una red privada de confianza. Son para configuraciones especiales. Un inicio de sesión es la mejor opción. Consulta Control de acceso para ver los indicadores y sus riesgos.

Bypass de Tailscale y Docker

De forma predeterminada, Marinara confía en un dispositivo que se conecta directamente a tu red Tailscale. También confía en el propio host de un contenedor Docker. Un inicio de sesión, una lista de IP permitidas o TRUSTED_AUTH_PROXY detienen la confianza automática de Docker, así que cada dispositivo necesita entonces su inicio de sesión o su lugar en la lista permitida. Para ver los indicadores que cambian esto, consulta Control de acceso.

Docker Desktop, OrbStack y Docker sin root (rootless) muestran todos los dispositivos que usan un puerto publicado con la dirección de la puerta de enlace de Docker. Si publicas el puerto en todas las interfaces (-p 7860:7860) y no configuras un inicio de sesión, cualquiera en tu red puede entrar. Mantén el puerto en 127.0.0.1 o configura primero un inicio de sesión. El registro del servidor avisa de esto al arrancar.

Proxies inversos y túneles en la misma computadora

Un proxy inverso o un túnel en la máquina que ejecuta Marinara, como nginx, Caddy, Traefik, Cloudflare Tunnel, Tailscale Serve o Funnel, o ngrok, se conecta a Marinara desde loopback. Marinara lo reconoce por los encabezados de reenvío que añade el proxy: Forwarded, X-Forwarded-For, X-Real-IP, X-Forwarded-Host, X-Forwarded-Proto, CF-Connecting-IP, True-Client-IP, los encabezados de identidad de Tailscale o Via. Marinara también reconoce una solicitud que llega por HTTP/1.0, porque los navegadores nunca lo usan pero un proxy_pass predeterminado de nginx sí. Marinara también reconoce una solicitud cuyo Host nombra a otra computadora, como un dominio o una dirección LAN, incluso cuando el proxy no añade encabezados. Entonces trata cada solicitud como el visitante remoto que es:

Tu propio navegador en esa máquina, abierto en http://127.0.0.1:7860 o http://localhost:7860, sigue sin contraseña.

Caddy, Traefik, Cloudflare Tunnel, Tailscale y ngrok añaden encabezados de reenvío de forma predeterminada. Para nginx, esta línea se sigue recomendando en el bloque location:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Las herramientas que reenvían conexiones sin procesar, como socat o ssh -R, no añaden encabezados, así que su tráfico parece local. No las uses para publicar Marinara.

Si tu proxy ya hace iniciar sesión a cada visitante antes de reenviar algo, consulta Proxies de inicio de sesión (forward auth).

Proxies de inicio de sesión (forward auth)

Un proxy de forward auth, como tinyauth, Authelia, Authentik u oauth2-proxy, pide a cada visitante iniciar sesión antes de reenviar la solicitud. Si un proxy así es la única forma de llegar a Marinara, puedes saltarte el segundo inicio de sesión de Marinara. No lo configures sin un proxy así.

Pon la dirección del proxy en .env:

TRUSTED_AUTH_PROXY=192.168.1.5

Marinara deja entrar entonces cada solicitud cuya conexión venga de esa dirección. Marinara no pide su propio inicio de sesión para ellas, ni imprime ningún código de configuración. Marinara comprueba la dirección de la propia conexión. Ignora para esta decisión los encabezados de reenvío como X-Forwarded-For. Las solicitudes del proxy también pasan IP_ALLOWLIST, porque el proxy decide quién entra. No cuentan como locales, así que las acciones privilegiadas siguen necesitando el secreto de administrador. Settings → Advanced → Access muestra Trusted login proxy: Set mientras el ajuste está activo.

Antes de configurarlo:

Cuando TRUSTED_AUTH_PROXY está configurado, Marinara también detiene la confianza automática de Docker. Los visitantes directos que no son el proxy necesitan el inicio de sesión de Marinara o la lista de IP permitidas. Marinara deja entonces de mostrar también un banner de "no login yet" (todavía no hay inicio de sesión).

Si el proxy se ejecuta en la misma computadora que Marinara, usa TRUSTED_AUTH_PROXY=127.0.0.1 y apunta el proxy a 127.0.0.1:7860, no a localhost:7860. Un proxy que marca a localhost puede conectarse desde ::1, que no coincide con 127.0.0.1. Entonces también se confía en cualquier otro proxy o túnel de esa computadora, así que úsalo solo cuando el proxy de inicio de sesión sea el único. Esto no da a los visitantes con proxy el acceso de la máquina local.

Un ejemplo de Caddy, con Marinara en 192.168.1.20:7860:

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

Para Authelia, usa forward_auth authelia:9091 con uri /api/authz/forward-auth. Authentik también sirve sus propias páginas de inicio de sesión a través del proxy. Pon sus líneas en un bloque route para que Caddy conserve su orden y la ruta del outpost no pase por el propio 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
  }
}

Para Traefik y nginx, sigue la guía de forward-auth de tu proxy. Marinara no necesita nada más que la dirección del proxy.

Servir por HTTPS

HTTPS cifra la conexión usando TLS. TLS es el cifrado que convierte una dirección http simple en una https segura. Usa siempre HTTPS para cualquier instalación accesible fuera de una red privada totalmente de confianza, sobre todo con Basic Auth.

Tienes dos formas de agregarlo.

  1. TLS integrado. Apunta el servidor a un archivo de certificado y de clave privada:
SSL_CERT=/path/to/cert.pem
SSL_KEY=/path/to/key.pem
  1. Proxy inverso. Pon Marinara detrás de nginx, Caddy, Traefik o un Cloudflare Tunnel. El proxy maneja la parte de HTTPS y reenvía a Marinara por HTTP simple en la misma máquina. Lee primero Proxies inversos y túneles en la misma computadora.

Necesitas un certificado y una clave antes de configurar SSL_CERT y SSL_KEY. Puedes crear uno con una herramienta como mkcert para uso local, o certbot para un dominio público. Si los archivos faltan o no se pueden leer, el servidor se detiene al arrancar y nombra las rutas exactas que intentó.

Admin Access y acciones privilegiadas

Algunas acciones son especialmente sensibles: borrar datos, crear o descargar copias de seguridad, importar y exportar perfiles, instalar temas y agentes, e instalar el runtime del Local Model. Estas necesitan un secreto compartido aparte llamado el secreto de admin, además de la opción de acceso que hayas elegido arriba.

En la máquina loopback, estas acciones suelen funcionar sin secreto de admin. Desde un dispositivo remoto, necesitas configurar el secreto. Puedes crearlo en la app o configurarlo en .env.

Los agentes instalados, como los de la pantalla de inicio, no necesitan el secreto de admin. Un dispositivo que entró con el inicio de sesión puede usarlos. Instalar, actualizar y quitar un agente siguen necesitándolo.

Crear el secreto de admin en la app

  1. En la computadora que ejecuta Marinara, abre Settings (Configuración), luego la pestaña Advanced (Avanzado), luego la sección Admin Access (Acceso de administrador).
  2. Haz clic en Make admin secret (Crear secreto de admin). Marinara muestra el secreto nuevo una sola vez y lo guarda en este navegador.
  3. En cada dispositivo remoto, abre Settings → Advanced → Admin Access, escribe el secreto en la casilla y luego haz clic en Save (Guardar). Las mayúsculas, los espacios y los guiones no importan.

Un dispositivo que ya tiene el secreto también puede crearlo. Un dispositivo que solo entró con el inicio de sesión no puede. Esto impide que un inicio de sesión robado tome el control de las acciones de riesgo.

Con Docker, tu navegador llega a Marinara a través de la red de Docker, así que Marinara no lo trata como la misma computadora. Configura el primer secreto en .env en su lugar (consulta más abajo).

Para cambiar el secreto, haz clic en Replace admin secret (Reemplazar secreto de admin). El secreto anterior deja de funcionar en todos los dispositivos. Para desactivarlo, haz clic en Remove admin secret (Quitar secreto de admin). Marinara guarda solo una huella del secreto, en .admin-secret.json en la carpeta de datos. Borrar ese archivo también quita el secreto.

Configurar el secreto de admin en .env

  1. En .env, configura un valor aleatorio fuerte y guarda. Se aplica en un par de segundos, sin reiniciar.
ADMIN_SECRET=some-long-random-string
  1. En el dispositivo remoto, abre Settings → Advanced → Admin Access.
  2. Pega el mismo valor en la casilla (su marcador de posición dice ADMIN_SECRET), luego haz clic en Save.
  3. Deberías ver el mensaje Admin secret saved for this browser (Secreto de admin guardado para este navegador).

ADMIN_SECRET en .env tiene prioridad sobre un secreto creado en la app. Mientras está configurado, Admin Access lo indica y solo cambias el secreto en .env.

Conviene saber

Si una acción privilegiada falla en un dispositivo remoto, Marinara muestra un mensaje de error con dos soluciones. Una solución es abrir la app a través de localhost. La otra es configurar el secreto de admin como se describe arriba.

Por qué mi guardado está bloqueado (CSRF)

CSRF significa cross-site request forgery (falsificación de solicitud entre sitios). Es una protección que impide que otro sitio web que tengas abierto haga cambios silenciosamente en Marinara sin tu permiso. Funciona automáticamente. No hay ningún ajuste para activarlo.

A veces CSRF bloquea tus propios guardados. Esto suele pasar cuando llegas a Marinara a través de un nombre de dominio público o un puerto inusual en el que el servidor aún no confía. Dos cosas te avisan cuando esto pasa.

Para arreglarlo, agrega tu dirección a la lista de confianza en .env:

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

Cuando usas un dominio público o de proxy inverso, permite también el nombre de host:

TRUSTED_HOSTS=chat.example.com

Las direcciones directas de LAN, Tailscale, IPv4 e IPv6 no necesitan TRUSTED_HOSTS. Los nombres locales .local/.home.arpa y los nombres de máquina de una sola etiqueta se aceptan automáticamente. Un nombre de host exacto que ya esté en CSRF_TRUSTED_ORIGINS también se acepta.

Loopback, las direcciones normales de LAN, Tailscale (100.64.0.0/10) y los orígenes de puente de Docker (172.16.0.0/12) son de confianza automáticamente. Solo necesitas listar direcciones IP públicas y nombres de dominio. El cambio surte efecto en un par de segundos, sin necesidad de reiniciar.

Una nota sobre proveedores locales bloqueados

Digamos que conectas Marinara a un proveedor de IA local, por ejemplo uno que se ejecuta en tu propia máquina. La solicitud puede rechazarse con un mensaje sobre un "private, loopback, metadata, or reserved IP range" (rango de IP privado, loopback, de metadatos o reservado). Esa es una comprobación de seguridad distinta llamada protección SSRF. SSRF significa server-side request forgery (falsificación de solicitud del lado del servidor). Impide que el servidor llame a direcciones privadas salvo que lo permitas. El error nombra la variable .env exacta que hay que configurar, como PROVIDER_LOCAL_URLS_ENABLED. Consulta Referencia de configuración del servidor para ver la lista completa.

Acceso desde un teléfono o una tableta

Para abrir Marinara desde un teléfono o una tableta en la misma red:

  1. Asegúrate de que el servidor escuche en todas las interfaces con HOST=0.0.0.0 en .env.
  2. Configura un inicio de sesión (Opción 1 arriba). Desde el teléfono, puedes hacerlo en la página que lo bloquea, con el código de configuración del registro del servidor.
  3. Encuentra la dirección IP local de la máquina del servidor (por ejemplo 192.168.1.50).
  4. En el teléfono, abre http://192.168.1.50:7860 en un navegador. El puerto predeterminado es 7860.
  5. Inicia sesión con tu nombre de usuario y tu contraseña.

Si la página no carga en absoluto, puede que el servidor no sea accesible. Revisa HOST=0.0.0.0 y el valor de PORT. Si en cambio recibes un 403, tu dispositivo es accesible pero aún no está permitido. Vuelve a revisar la opción que elegiste arriba.

Bloqueado después de actualizar

Las versiones nuevas piden un inicio de sesión cuando una visita llega a través de un proxy inverso, un túnel, Tailscale Serve o Tailscale Funnel. Las versiones anteriores dejaban entrar estas visitas sin contraseña. Si ahora ves una página de inicio de sesión, una página de configuración o un 403, esta es la razón.

Nota de actualización: si usas Tailscale Serve, u otro proxy en la misma computadora, y nunca configuraste una contraseña, tus otros dispositivos quedan bloqueados tras la actualización. Un proxy en la misma computadora suele hablar con un servidor que escucha solo en loopback, así que el servidor no imprime ningún código de configuración. Configura en su lugar el inicio de sesión en la computadora que ejecuta Marinara.

Para volver a entrar:

  1. Abre Marinara en la computadora que lo ejecuta, en http://localhost:7860 (o en tu propio PORT). El uso local no necesita contraseña. En un servidor sin pantalla, ejecuta primero ssh -L 7860:127.0.0.1:7860 user@server en tu propia computadora y luego abre allí http://localhost:7860. En Docker, esto solo funciona mientras no haya inicio de sesión ni IP_ALLOWLIST configurados. En otro caso, escribe el código de configuración del registro del servidor (docker logs <container> 2>&1 | grep "setup code") en la página que te bloquea o en Settings → Advanced → Access, o usa un navegador que aún tenga la sesión iniciada.
  2. Ve a Settings → Advanced → Access y configura un nombre de usuario y una contraseña en Remote login. O abre el archivo .env de esa computadora y configura BASIC_AUTH_USER y BASIC_AUTH_PASS. Si IP_ALLOWLIST está configurado, añade la dirección de tu otro dispositivo a la lista o quítala, porque un dispositivo que no está en la lista recibe un 403 incluso con un inicio de sesión.
  3. Inicia sesión desde tu otro dispositivo con ese usuario y contraseña.

Buscadores

Marinara pide a los buscadores que no indexen sus páginas (X-Robots-Tag: noindex, nofollow). Esto no protege tu instalación ni elimina las páginas que ya están indexadas. Usa los controles de acceso de arriba para mantener tu instalación privada.

Guías relacionadas