Hola Mario, gracias por este fantástico contenido.Mis sinceras felicitaciones. Por otro lado, quiero solicitarte, de la manera más respetuosa, que, por favor, crees una playlist con los videos de esta serie de angular, me refiero a los videos donde se construye la app desde el principio. Nos ayudaría mucho a los novatos porque nos gustaría seguir y aprender el proceso entero. He buscado en los videos (tienes muchos) y es muy difícil encontrarlos. Gracias.
¡Buenos días! La lista ya la teníamos creada, te la dejamos por aquí: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-EB9-bxI8whI.html . Esperamos que te sirva de ayuda. De hecho si te vas a la pestaña de Playlist: www.youtube.com/@Garajedeideas/playlists , tienes esta lista que te comentamos y después te puede ser útil también la de Angular-Firebase si quieres seguir con el mismo framework.
Si se agrega a mano un token_songs falso en el navegador alguien podría acceder igual a las secciones protegidas, no vería contenido pero si podría ver el código. Incluso si el guard se hace con una validación hacia la API se podría interpretar la petición y retornar una respuesta correcta ¿Existe alguna forma para evitar esto? O solo debo tener en cuenta que alguien con los conocimientos suficientes podrá ingresar y ver el código? Vengo de Laravel donde la autenticación permite tener un bloqueo efectivo ante el intento de ver el código de secciones protegidas y me he topado con que en Angular esto no se puede evitar.
Una práctica para poder evitar eso sería que, además de comprobar que tengas el token almacenado en LocalStorage, el propio guard podría lanzar una petición al back para comprobar que el token esté correcto. Como comentas, sería muy sencillo poder trampear el token a través de la consola
No es para nada obligatorio. Deberías usar el manejo de estado que tengas dentro de la aplicación. El uso de localStorage es un ejemplo para poder ver cómo a partir de una persistencia en el navegador podemos bloquear el acceso a la ruta
