Estoy tratando de pensar en diferentes formas de abordar esto. Un método es... Digamos que obtenemos un token que tiene un reclamo para un rol devuelto cuando un usuario inicia sesión. Para esta aplicación imaginaria tenemos 3 roles, super, administrador, invitado.
El token devuelve un valor de cadena en la propiedad del rol, por ejemplo, rol: "admin"
En la aplicación, construimos dos funciones, un routeBuilder y un navItemBuilder, para construir estos objetos que pasamos en la cadena de funciones, por ejemplo, "admin"
Luego, la aplicación representa las rutas correctas y los elementos de menú que están disponibles según el rol que tiene el usuario. por ejemplo, "invitado" solo tiene acceso a la página Acerca de y a las noticias... pero un súper también obtiene otro elemento de navegación llamado perfil o algo así...
Sin embargo, si uso las herramientas de desarrollo de reacción y edito el reclamo del rol del token, puedo hacer que la aplicación vuelva a generar una nueva ruta de navegación. Puedo cambiar la cadena de función del objeto token y luego, cuando actualice routeBuilder y navItemBuilder, construirá la nueva ruta en función de cualquier cadena que desee.
¿Cómo puedo crear roles en mi aplicación y evitar este problema de seguridad?
No se debe construir nada sensible en la propia aplicación.
Aplicar seguridad a nivel de servidor.
No debería importar si, por ejemplo, el usuario puede mostrar la interfaz de usuario para la ruta de administración.
Cuando su navegador solicita los datos necesarios para completarlo desde el servidor, el servidor debe realizar AuthZ y devolver un error en lugar de (por ejemplo) una lista de usuarios que se pueden administrar.
Su código del lado del cliente puede manejar el error, de modo que si el usuario termina allí por accidente (por ejemplo, si es un usuario válido pero su sesión ha expirado), puede ser desviado a una pantalla de inicio de sesión o recibir un mensaje de error útil.