español - breeze significado
¿Cómo está manejando breeze.js la seguridad y evitando exponer la lógica empresarial? (3)
La seguridad es una preocupación vital. Es aconsejable pensar detenidamente sobre los datos y la lógica expuestos en el cliente. ¿Cómo podemos refinar estos sentimientos en una pregunta concreta adecuada para una respuesta SO?
Nada acerca de Breeze debería hacer que expongas la lógica empresarial al cliente de JavaScript. Puede (y debe) bloquear dicha lógica de forma segura dentro de sus repositorios y / o métodos de controlador.
Pero me cuesta comprender cómo las consultas de los clientes son los tipos de lógica empresarial que necesitan protección. ¿Dónde está el peligro en una consulta para un cliente cuyo nombre comienza con ''A''?
Puede preocuparse por una consulta para clientes con un valor neto> $ 100,000. Pero el error no está en la consulta. El error sería exponer dicha información del cliente a usuarios no autorizados por cualquier medio , ya sea a través de una cláusula Breeze where añadida a una consulta o una llamada a un servicio llamado GetCustomers () .
El lugar para bloquear el acceso no autorizado a los clientes se encuentra en el servidor y usted puede hacerlo fácilmente dentro de un método de acción del controlador Breeze devolviendo IQueryable como sea posible en su método GetCustomer () . La carga recae sobre usted en cualquier caso para imponer las restricciones de seguridad necesarias en su controlador y dentro de los métodos que expone.
Usted escribe el controlador. Usted escribe los repositorios. Usted tiene acceso a los permisos del usuario. Usted tiene el control total con una capacidad sin concesiones para exponer tanto o tan poco como desee.
FWIW, su Breeze EntityManager puede llamar a los métodos de servicio que no devuelven IQueryable<Customer> . Puede llamar a los métodos de controlador Web Api como IEnumerable<Customer> GetCustomers() o Product GetProductForId(int id) . En mi opinión, perderá la flexibilidad de las instalaciones de consulta de Breeze sin obtener ningún tipo de seguridad. Pero esa es solo mi opinión. Breeze apoyará su elección, cualquiera que sea.
Me encantaría intentar responder una pregunta más específica sobre "cómo hacerlo".
Estamos considerando breeze js para crear aplicaciones empresariales.
La maravilla de la brisa es que podemos ejecutar consultas directamente desde el navegador del cliente. Esto permite construir consultas dinámicas basadas en la entrada de los usuarios sin cargar datos innecesarios. Descubrí que al usar Breeze podemos crear una lógica comercial que reduce la transferencia / transferencia de datos en 1/10 o incluso más cuando se utiliza una estrategia de carga diferida. usando consultas como these
Hooray breeze !!!
Pero, ¿qué pasa con la seguridad de Business Logic? Por ejemplo, podríamos tener un repositorio en el que pudiéramos ocultar, esconder y oscurecer nuestra lógica comercial; y luego use los controladores de la API web de MVC para realizar llamadas a las clases de repositorio C #. así que Breeze JavaScript habla con el controlador WebAPi y el controlador de WebApi habla con el repositorio de C #. Los Controladores siempre se mantendrán muy simples y fáciles de leer, pero el Repositorio puede terminar teniendo mucha lógica comercial para la compañía que usa la aplicación. Entonces, si un hacker usa, por ejemplo, la consola del desarrollador de Google Chrome para inspeccionar el código JavaScript, todo lo que verá son cosas como GetCustomers (), GetProductsForThisId (54). No hay mucha información que se pueda ver (o robar) allí. Porque el 90% de Business Logic vivirá en el repositorio de C # en el servidor.
¿Cómo está manejando breeze.js eso?
Si comenzamos a mover las consultas y la lógica comercial "desde el C # del controlador hasta el comodín JavaScript", tenemos que considerar que nuestro sistema está basado en la membresía. Creo que mientras más consultas exponemos al cliente en JavaScript, más vulnerable se vuelve nuestro software y más le decimos a los hackers cómo hackear nuestro sitio web y posiblemente robar información.
Puedes usar un montón de cosas con breeze.js Antes de nada, comprueba mi respuesta con respecto a la seguridad aquí.
Cómo manejar la autorización con Breeze JS?
Además, aunque breeze.js se puede utilizar como un ORM normal en el cliente (que a veces puede ser extremadamente útil), debe mantener su lógica comercial en los controladores de API web y exponer solo las cosas necesarias mediante consultas OData. Si necesita alguna lógica de manipulación de datos, entonces debe hacerlo en el servidor utilizando un método específico para eso.
Solo la lógica de la interfaz de usuario debe estar presente en el cliente, también debe tener en cuenta que existen varias implicaciones de rendimiento si comienza a realizar múltiples consultas directamente desde el cliente. O expanda el gráfico de entidad para cargar más resultados o use métodos más especializados que devuelvan el objeto. Breeze introspectirá los resultados y consumirá a las entidades felizmente sin implicaciones.
Quisiera agregar que puede restringir a los usuarios que no están autorizados de la ejecución mediante el uso de los atributos en webapi si obtiene un código 401 del servidor, solo aparece una pantalla de inicio de sesión y rehace el trabajo necesario después de que el usuario haya iniciado sesión.
por lo que un usuario puede tratar de obtener datos sobre un pedido, pero no lo obtendrá a menos que esté autorizado para hacerlo