Shares, rutas y configuración

Diseño previsto; aún no implementado.

Un solo concepto: el share

En la 2.0 se distinguía "servir una web" y "compartir una carpeta". En la 3 son lo mismo: un share publica una carpeta del disco en una location (ruta URL) y se ofrece a la vez por web, FTP y WebDAV.

• Si la carpeta pedida tiene documento índice (index.html por defecto), la web lo sirve.
• Si no lo tiene y el listado está permitido, se muestra el navegador de directorios.
• ?$list fuerza el navegador de directorios aunque haya índice (p. ej. /web/?$list), si el share tiene Listing. Así se puede ver y descargar el contenido de una carpeta que publica una web. El $ evita chocar con los parámetros que use la propia web.
• Una URL directa a un fichero lo descarga (o el navegador lo muestra, según su tipo MIME).

Locations: gana la más específica

Cada share tiene una Location (/, /fotos, /fotos/viaje…). Se resuelve como las locations de prefijo de nginx: gana el prefijo más largo.

• El prefijo se compara por segmentos completos: /foto no captura /fotos.
• La comparación no distingue mayúsculas y minúsculas; el resto de la ruta sigue las reglas del sistema de ficheros del share.
• /fotos sin barra final redirige a /fotos/.

Ejemplo:

Directorios virtuales y ocultación

• Al listar una carpeta, las locations hijas aparecen como carpetas aunque no existan en disco: en /fotos/ aparece 2026/ aunque D:\Fotos\2026 no exista, y dentro viaje/.
• Si existe una carpeta real con el mismo nombre que una location hija, queda tapada por ella (como en nginx, lo específico tiene prioridad).
• Los segmentos intermedios sin share propio son directorios virtuales de solo lectura.
• FTP y WebDAV ven exactamente el mismo árbol que la web.

La raíz

Rutas reservadas

/$sunfish/ está reservado para los recursos internos (iconos, CSS, JS), el panel de administración (/$sunfish/admin/) y la autodescarga del ejecutable (/$sunfish/download). Ninguna location puede empezar por /$sunfish.

Los parámetros propios de Sunfish en la URL empiezan por $ (?$list) o son de una letra reconocida solo en páginas generadas (?p=, ?ui=, ?sort=, ?as=). Una web servida desde un share recibe sus propios parámetros sin interferencias.

Validación de rutas

Toda ruta de web, FTP o WebDAV pasa por la misma validación antes de tocar el disco:

• Se decodifica (%XX) una sola vez y se normaliza el separador a /.
• Se rechazan: .. y . como componentes, \, : (flujos alternativos de NTFS), NUL y caracteres de control, y rutas absolutas incrustadas.
• En Windows se rechazan además los nombres reservados (CON, PRN, AUX, NUL, COM1–COM9, LPT1–LPT9) y los nombres acabados en punto o espacio.
• Se calcula la ruta real y se comprueba que queda dentro de la carpeta del share. Los enlaces simbólicos y junctions cuyo destino sale del share no se siguen.

(La 2.0 hacía Path.Combine sin validar: este es el cambio de seguridad más importante.)

Permisos

Por share, todos desactivados por defecto salvo la lectura:

Adaptaciones automáticas, activadas por defecto (solo se configuran para desactivarlas):

Usuarios: si un share tiene Users, todo acceso (web, FTP, WebDAV) requiere usuario y contraseña de esa lista; si no, es público. Pendiente: permisos distintos por usuario dentro de un mismo share (p. ej. lectura pública y escritura con usuario).

Fichero de configuración

INI editable a mano, con claves en inglés (los mensajes al usuario van en español o inglés).

# sunfish.conf

[Server]
Name = Sunfish
HttpPort = 8080
FtpPort = 2121
FtpPassivePorts = 50000-50050
Bind = 0.0.0.0, ::
RootMenu = true
SelfDownload = true

[Admin]
Enabled = false
PasswordHash = <PBKDF2>
AllowFrom = 127.0.0.1, ::1

[User ana]
PasswordHash = <PBKDF2>

[Share web]
Location = /
Path = C:\www
Index = index.html
Listing = false

[Share fotos]
Location = /fotos
Path = D:\Fotos
Listing = true
Upload = true
Zip = true
Users = ana

[Share juegos-mac]
Location = /archivo
Path = D:\Archivo
# Coleccion de .bin/.hqx que deben quedarse codificados
Mac = false

• Valores por defecto: Index = index.html (vacío = sin índice), Listing = true, Ftp = true, WebDav = true, Mac = true, ShortNames = true, Enabled = true, el resto de permisos false.
• La GUI, la TUI, los subcomandos y el panel web reescriben el fichero conservando comentarios y orden, con escritura atómica (temporal + renombrado).
• Un cambio en el fichero hecho por otro proceso se detecta y se recarga; si no es válido se conserva la configuración anterior y se anota en el registro.

Ubicación

La primera que exista:

1. -c FICHERO (o --config).
2. sunfish.conf junto al ejecutable (modo portable).
3. Carpeta de configuración del usuario: %APPDATA%\Sunfish\sunfish.conf, ~/.config/sunfish/sunfish.conf (o $XDG_CONFIG_HOME), ~/Library/Application Support/Sunfish/sunfish.conf.

Si no existe ninguna, la aplicación ofrece crearla junto al ejecutable o en la carpeta del usuario. Sunfish.exe y sunfish-cli usan el mismo formato y las mismas rutas, así que pueden compartir configuración (no a la vez: competirían por los puertos).

Importar la configuración de la 2.0

La 2.0 guardaba un JSON llamado sunfish2 en el directorio de trabajo. Implementado en Config/LegacyImport.cs (fase 7, con JsonDocument, compatible con AOT):

• Al crear la configuración (GUI y TUI), si existe sunfish2 junto al ejecutable o en la carpeta actual, se ofrece importarlo.
• En cualquier momento: sunfish-cli import-v2 [FICHERO] añade sus shares a la configuración existente (o la crea).
• Los nombres de las claves se leen sin distinguir mayúsculas; Settings se acepta como objeto o como lista de pares Key/Value.
• Si un nombre o una location ya existen, se usa uno libre (fotos-2). Los nombres con espacios se juntan (en el INI no valen).
• El puerto y el menú raíz solo se copian si la configuración es nueva. Un puerto por debajo de 1024 (la 2.0 usaba 90) se cambia por 8080, porque no se pide administrador.
• Al terminar se listan las notas: lo ignorado y las carpetas que no existen.