He estado trabajando en seguridad lógica basada en la información del usuario actual, como por ejemplo: ‘si topic.creator.username es igual a User.current().username’, permito que el usuario edite o elimine el tema.
El punto es que necesito garantizar ciertas acciones basadas en la sesión del usuario. Sin embargo, he realizado algunas pruebas y por eso estoy aquí preguntándoles.
A través de JavaScript en el navegador web (incluso en modo producción), puedo ejecutar Discourse.User.current().set(‘username’, ‘sometestename’). De esta manera, algunas acciones en mi sistema se habilitarían solo con ese cambio. Sé que no es el objetivo del 99% de los usuarios, pero más allá de este caso, ¿alguien sabe alguna forma de asegurarse de que el usuario no pueda manipular la información de su cuenta?
Si cambias información en tu navegador local, eso no modifica nada en el backend.
El usuario ha iniciado sesión mediante un token de autenticación, creo, por lo que no puedes suplantar a otra persona ante el backend:
Dado que no es posible engañar al servidor, no podrás realizar ningún cambio como otro usuario.
Tan pronto como actualices el navegador, es probable que tus cambios locales se borren. En el peor de los casos, es probable que alteres el estado de la aplicación de JavaScript y tengas que borrar tu caché.
Como dijiste, la mejor manera sería obtener siempre la sesión del usuario actual desde el servidor backend.
De esta forma, los cambios en la caché del navegador no podrían afectarla. ¿Sabes dónde puedo verificar que la seguridad lógica se basa en la sesión del usuario desde el servidor backend y no desde PreloadStore?
Avísame si estoy señalando el camino equivocado. ¡Gracias, Robert, por la ayuda!
No soy un experto en seguridad, solo un desarrollador de aplicaciones, pero todos los cambios persistentes solo pueden realizarse en el servidor. Lo que ocurre en el navegador con EmberJS es para la comodidad del usuario y una mejor experiencia de usabilidad, por ejemplo, la caché para mayor velocidad y el comportamiento automático de la interfaz tipo aplicación. Esto no cambia el hecho de que, en última instancia, debe negociar todos los cambios persistentes con el servidor de Rails y, al hacerlo, solo tendrá permiso para hacerlo en nombre del usuario que ha iniciado sesión.
Lo mismo ocurre con toda la recuperación de datos: el servidor de Rails solo enviará los datos a los que el usuario que ha iniciado sesión tenga acceso.
No creo que necesites preocuparte por esto, porque si alguien intentara subvertir este proceso, tropezaría en el primer obstáculo: no hay forma de engañar a la API.
Me preocupa porque estoy trabajando en algunas aproximaciones donde esa acción estará disponible o no dependiendo del usuario, si eres el creador del tema, si eres el creador del post, así que de esta manera necesito validar basándome en la sesión del usuario en el backend.
Como esto, en el post el usuario puede editarlo, si eres el creador del post.
EDITO: Al igual que los permisos de los posts en Discourse, lo revisaré.
He estado analizando el código del plugin y la base de código sobre los controles de publicaciones (acciones) para determinar en qué aspectos puedo contribuir más a la seguridad.
Como se analizó: en el front-end hay varios pasos que verifican si el usuario puede editar o no la publicación, como:
