Prevención paginación a través del navegador
Quote from Juancasev on November 17, 2025, 3:18 pmHola,
Estoy usando neocms para la autenticación de usuarios en algunas de mis aplicaciones. Desde el modo debug del navegador, puede verse fácilmente la estructura de páginas de mi aplicacion. Para evitar la paginación manual a través de la barra de dirección del navegador, uso una variable de autenticacion de forma que en cada entrada de las paginas secundarias se verifica la variable de autenticación para ver si esta en modo "logueado" y devuelve a la pagina de login si no se esta en ese modo. No obstante, no estoy seguro si esta estrategia es efectiva o hay alguna forma mejor de evitar la paginación manual. Muchas gracias.
I'm using neocms for user authentication in some of my applications. From the browser's debug mode, the page structure of my application can be easily seen. To prevent manual pagination through the browser's address bar, I use an authentication variable so that each entry to the secondary pages checks the authentication variable to see if it's in "logged in" mode and redirects to the login page if it's not. However, I'm not sure if this strategy is effective or if there's a better way to prevent manual pagination. Thank you very much."
Hola,
Estoy usando neocms para la autenticación de usuarios en algunas de mis aplicaciones. Desde el modo debug del navegador, puede verse fácilmente la estructura de páginas de mi aplicacion. Para evitar la paginación manual a través de la barra de dirección del navegador, uso una variable de autenticacion de forma que en cada entrada de las paginas secundarias se verifica la variable de autenticación para ver si esta en modo "logueado" y devuelve a la pagina de login si no se esta en ese modo. No obstante, no estoy seguro si esta estrategia es efectiva o hay alguna forma mejor de evitar la paginación manual. Muchas gracias.
I'm using neocms for user authentication in some of my applications. From the browser's debug mode, the page structure of my application can be easily seen. To prevent manual pagination through the browser's address bar, I use an authentication variable so that each entry to the secondary pages checks the authentication variable to see if it's in "logged in" mode and redirects to the login page if it's not. However, I'm not sure if this strategy is effective or if there's a better way to prevent manual pagination. Thank you very much."
Quote from luishp on November 17, 2025, 8:51 pm@juancasev
- Lo que haces de comprobar una variable en cada página secundaria es correcto y recomendable dentro del cliente VisualNEO Web.
- No es una protección “a prueba de hackers” porque todo lo que está en el cliente puede ser manipulado.
- La seguridad real debes apoyarla en:
- neoCms (o neoLogin/neoPhp) para validar logins.
- Permisos y roles en el servidor.
- Solo servir datos sensibles si la autenticación es válida.
Ver la estructura de páginas en el navegador es normal
Ten en cuenta que en cualquier app hecha con VisualNEO Web, todo el HTML/JS viaja al navegador.
Por eso, con las herramientas de desarrollador:
- Se puede ver el listado de páginas (ids, hash, etc.).
- Se puede forzar la navegación a
#OtraPagina, aunque normalmente el usuario “normal” nunca lo hará.No existe forma 100% fiable de ocultar eso en el lado cliente.
Lo que sí puedes hacer es que, aunque alguien “fuerce” la navegación, la página:
- Le eche atrás al login, o
- No cargue datos sensibles desde el servidor si no está autenticado.
Tu sistema de variable de autenticación
Lo que comentas (tener una variable tipo
[authMode]y comprobarla en cada página secundaria) es un patrón muy habitual en VisualNEO Web.
Por ejemplo, en el evento Enter de cada página protegida:If [authMode] != "logueado" GotoPage "Login" EndIf
IfyEndIfson las instrucciones condicionales estándar.GotoPagees el comando de navegación a páginas.Ventajas de este enfoque:
- Evita que un usuario “curioso” simplemente escriba la URL de otra página y se quede en ella.
- Es fácil de mantener: solo tienes que añadir la comprobación en cada página/plantilla protegida.
Limitación importante:
Como todo esto es código que se ejecuta en el navegador, un usuario avanzado podría:
- Abrir la consola y cambiar la variable
[authMode]manualmente.- O manipular el flujo de ejecución.
Por eso este mecanismo es más bien un “control de acceso visual/UX”, no una seguridad fuerte por sí solo.
Dónde entra realmente neoCms en la seguridad
Con neoCms tienes autenticación de usuario + permisos sobre contenido en el servidor:
neoCmsLoginautentica y te devuelve información de usuario y API key / token.- Puedes definir usuarios y grupos con diferentes permisos (colecciones, formularios, etc.).
La clave es esta idea:
Aunque alguien llegue a una “página privada”, no podrá leer ni modificar datos sensibles de neoCms si no tiene los permisos adecuados.
Por tanto, lo más seguro es:
- Usar tu variable
[authMode]solo como “candado de interfaz” (mostrar/ocultar páginas, botones, etc.).- Y que los datos privados (artículos, usuarios, operaciones críticas, etc.) vengan siempre de neoCms, usando comandos tipo:
neoCmsGetCollection,neoCmsAddCollectionItem,neoCmsUpdateCollectionItem, etc.- Configurar bien los permisos en neoCms, de forma que un usuario sin login (o con rol inadecuado) no pueda acceder a esos endpoints aunque descubra la URL.
Así, incluso si alguien “hackea” la navegación y llega a
#PaginaAdmin, se encontrará:
- La interfaz, sí.
- Pero todas las llamadas a neoCms fallarán o devolverán vacío si no está logueado / autorizado.
- Lo que haces de comprobar una variable en cada página secundaria es correcto y recomendable dentro del cliente VisualNEO Web.
- No es una protección “a prueba de hackers” porque todo lo que está en el cliente puede ser manipulado.
- La seguridad real debes apoyarla en:
- neoCms (o neoLogin/neoPhp) para validar logins.
- Permisos y roles en el servidor.
- Solo servir datos sensibles si la autenticación es válida.
Ver la estructura de páginas en el navegador es normal
Ten en cuenta que en cualquier app hecha con VisualNEO Web, todo el HTML/JS viaja al navegador.
Por eso, con las herramientas de desarrollador:
- Se puede ver el listado de páginas (ids, hash, etc.).
- Se puede forzar la navegación a
#OtraPagina, aunque normalmente el usuario “normal” nunca lo hará.
No existe forma 100% fiable de ocultar eso en el lado cliente.
Lo que sí puedes hacer es que, aunque alguien “fuerce” la navegación, la página:
- Le eche atrás al login, o
- No cargue datos sensibles desde el servidor si no está autenticado.
Tu sistema de variable de autenticación
Lo que comentas (tener una variable tipo [authMode] y comprobarla en cada página secundaria) es un patrón muy habitual en VisualNEO Web.
Por ejemplo, en el evento Enter de cada página protegida:
If [authMode] != "logueado" GotoPage "Login" EndIf
IfyEndIfson las instrucciones condicionales estándar.GotoPagees el comando de navegación a páginas.
Ventajas de este enfoque:
- Evita que un usuario “curioso” simplemente escriba la URL de otra página y se quede en ella.
- Es fácil de mantener: solo tienes que añadir la comprobación en cada página/plantilla protegida.
Limitación importante:
Como todo esto es código que se ejecuta en el navegador, un usuario avanzado podría:
- Abrir la consola y cambiar la variable
[authMode]manualmente. - O manipular el flujo de ejecución.
Por eso este mecanismo es más bien un “control de acceso visual/UX”, no una seguridad fuerte por sí solo.
Dónde entra realmente neoCms en la seguridad
Con neoCms tienes autenticación de usuario + permisos sobre contenido en el servidor:
neoCmsLoginautentica y te devuelve información de usuario y API key / token.- Puedes definir usuarios y grupos con diferentes permisos (colecciones, formularios, etc.).
La clave es esta idea:
Aunque alguien llegue a una “página privada”, no podrá leer ni modificar datos sensibles de neoCms si no tiene los permisos adecuados.
Por tanto, lo más seguro es:
- Usar tu variable
[authMode]solo como “candado de interfaz” (mostrar/ocultar páginas, botones, etc.). - Y que los datos privados (artículos, usuarios, operaciones críticas, etc.) vengan siempre de neoCms, usando comandos tipo:
neoCmsGetCollection,neoCmsAddCollectionItem,neoCmsUpdateCollectionItem, etc. - Configurar bien los permisos en neoCms, de forma que un usuario sin login (o con rol inadecuado) no pueda acceder a esos endpoints aunque descubra la URL.
Así, incluso si alguien “hackea” la navegación y llega a #PaginaAdmin, se encontrará:
- La interfaz, sí.
- Pero todas las llamadas a neoCms fallarán o devolverán vacío si no está logueado / autorizado.