Los repositorios institucionales modernos suelen integrarse dentro de ecosistemas tecnológicos cada vez más complejos. Es habitual que un repositorio DSpace conviva con portales institucionales, plataformas de gestión documental, sistemas desarrollados a medida e incluso aplicaciones de terceros, compartiendo el mismo dominio, certificados SSL y mecanismos de autenticación.
Esa integración entrega una experiencia transparente para los usuarios, pero también puede originar problemas extremadamente difíciles de diagnosticar cuando dos aplicaciones, completamente independientes, comienzan a interferir entre sí.
Recientemente, durante labores de soporte sobre un repositorio institucional basado en DSpace 7, nos encontramos con uno de esos escenarios.
Cuando el problema parecía estar en DSpace
El síntoma parecía simple: era imposible iniciar sesión en el panel administrativo del repositorio.
La interfaz cargaba correctamente, el API REST respondía, Solr funcionaba sin inconvenientes, Tomcat estaba operativo, PostgreSQL no registraba errores y el frontend Angular mostraba toda la información pública del repositorio.
Sin embargo, cada intento de autenticación terminaba exactamente igual:
403 Forbidden
Invalid CSRF TokenA primera vista todo apuntaba a un problema interno de DSpace y precisamente ahí comenzó la investigación.
Las primeras hipótesis
Cuando un inicio de sesión falla en DSpace, normalmente existen varios candidatos evidentes. Se revisó cuidadosamente la configuración de Nginx, el funcionamiento de Tomcat, la configuración del config.json, las URLs del API REST, la configuración de CORS, los certificados SSL, las diferencias entre dspace.server.url y dspace.ui.url, además del funcionamiento general del backend.
También se descartaron problemas de permisos sobre el frontend Angular, configuraciones de SELinux, errores de despliegue y posibles inconvenientes en la publicación del contexto REST.
Todo parecía correcto y, sin embargo, el login seguía fallando.
La pista que cambió completamente la investigación
La verdadera pista apareció revisando cuidadosamente los registros del backend de DSpace. Entre los mensajes generados por Spring Security apareció repetidamente el siguiente error:
Invalid CSRF TokenSin embargo, lo realmente interesante no era el mensaje, era el contenido del token recibido.
En lugar del UUID que normalmente utiliza DSpace, el sistema estaba recibiendo un token cifrado con un formato completamente distinto:
eyJpdiI6...Ese formato no pertenecía a DSpace. Pertenecía a Laravel. En ese momento quedó claro que el problema probablemente ni siquiera estaba en el repositorio.
Cuando dos aplicaciones comparten el mismo dominio
El repositorio DSpace convivía bajo el mismo dominio que otra aplicación institucional desarrollada en Laravel. Ambas aplicaciones funcionaban correctamente y de forma independiente, pero compartían el mismo dominio. Laravel generaba sus cookies de sesión y protección CSRF con el siguiente alcance:
Path=/Mientras tanto, DSpace emitía sus propias cookies únicamente para:
/serverComo consecuencia, al iniciar sesión en DSpace el navegador enviaba el token CSRF generado por Laravel en lugar del correspondiente al repositorio.
Desde la perspectiva del backend de DSpace, la petición era completamente inválida, por lo que respondía correctamente con un error 403 Forbidden.
¿Por qué fue tan difícil de detectar?
Porque absolutamente todos los síntomas apuntaban hacia DSpace.
- El repositorio cargaba normalmente.
- Las búsquedas funcionaban.
- El API REST respondía correctamente.
- Solr indexaba sin inconvenientes.
- Tomcat no registraba errores importantes.
Nada hacía pensar que la causa real estuviera en otra aplicación completamente distinta. Solo al revisar cuidadosamente el contenido del token CSRF fue posible descubrir que el navegador estaba enviando información generada por Laravel y no por DSpace.
La solución
Una vez identificado el origen del problema, la corrección resultó sorprendentemente sencilla.
En la aplicación Laravel se modificó la configuración de sesiones ubicada en:
/var/www/aplicacion/config/session.phpOriginalmente la aplicación generaba las cookies con el siguiente alcance:
'path' => '/'La configuración fue modificada a:
'path' => '/sitiolaravel'Posteriormente se ejecutó la limpieza de la caché de configuración de Laravel:
php artisan config:clear
php artisan cache:clear
php artisan config:cacheFinalmente se reinició Apache para aplicar los cambios.
Desde ese momento, cada aplicación volvió a utilizar exclusivamente sus propias cookies de autenticación y el acceso administrativo a DSpace comenzó a funcionar inmediatamente, sin modificar una sola línea del código del repositorio.
Una lección para quienes administran repositorios DSpace
Este caso demuestra que administrar un repositorio institucional basado en DSpace no consiste únicamente en conocer Tomcat, PostgreSQL o Solr.
Cuando un repositorio comparte dominio con otras aplicaciones, comprender cómo interactúan los navegadores, las cookies, los proxies reversos, los servidores web y los mecanismos de autenticación resulta igual de importante.
En muchas ocasiones el error visible aparece en DSpace, pero la causa real puede encontrarse completamente fuera del repositorio.
Reflexión final
Los problemas más complejos rara vez se resuelven modificando configuraciones al azar. Cada prueba descartada permitió reducir el universo de posibilidades. Cada registro revisado aportó una nueva pista.
Y finalmente fue el análisis detallado de los logs, del tráfico HTTP y del comportamiento de las cookies lo que permitió descubrir una causa que inicialmente parecía completamente ajena al repositorio.
En proyectos de DSpace, bibliotecas digitales y repositorios institucionales, muchas veces la solución definitiva no consiste en cambiar el repositorio, sino en comprender cómo convive con el resto de la infraestructura tecnológica.