rich que las internet importancia herramientas enriquecidas desventajas concepto application aplicaciones antecedentes ambiente actualidad ajax web-applications rich-internet-application onlinebanking

que - ¿Por qué no vemos mucho AJAX en aplicaciones seguras como la banca por Internet?



herramientas y aplicaciones web (7)

¿Puede alguien hacer una lista con referencias / evidencias si es posible, por qué no vemos mucho AJAX en aplicaciones web seguras como la banca por Internet?

Por ejemplo, la banca por Internet tiene una lista de pestañas para Cuentas, Pagos, Herramientas, Informes . Normalmente, verías estos implementados como enlaces a diferentes páginas. ¿Por qué no podría tener una sola página y usar AJAX para cargar el contenido de las diferentes pestañas? (por ejemplo, un control de ficha JSF RichFaces)

Supongo que los marcadores y el manejo del botón Atrás (o su desactivación, como es habitual en la banca por Internet) para las diferentes URL se manejarán en cualquiera de los casos. Entonces me gustaría escuchar otras cosas, ¿cómo podría afectar la seguridad, el rendimiento, etc.?

Mi equipo está a punto de comenzar a construir un sistema de administración de pagos basado en la web (piense en configurar pagos, gestionar saldos de cuentas de clientes, conciliación, etc.). No realizará los pagos reales, pero en algún momento se integrará con el sistema de banca por Internet de un banco líder.

Estamos divididos sobre el uso de una página y el uso de AJAX para todo lo demás

o

usando AJAX solo donde realmente ayuda a la experiencia del usuario.

Algunos problemas:

  • El sitio debe degradarse con gracia para los usuarios que tienen Javascript desactivado.
  • Problemas de accesibilidad: los usuarios con discapacidad necesitan lectores de pantalla y otras cosas que una aplicación habilitada para Ajax puede no proporcionar información suficiente para
  • Pruebas: debido a que se mantiene más estado en el navegador y a las dependencias más importantes en los navegadores, las aplicaciones habilitadas para Ajax tienen más problemas que pueden fallar, por lo que es más importante realizar pruebas en múltiples plataformas y navegadores.

Estos casos hacen que los sitios de Ajax sean más difíciles de construir, por lo que los bancos estarán menos ansiosos por seguir esa ruta.

Luego está toda la cosa de movimiento lento, corporativa y gigantesca, por supuesto. Los bancos se preocupan principalmente por reducir los costos, no por mantenerse al día con las tendencias de Internet.

Hay algunas entidades que siempre tienen 10 años de retraso en tecnología: bancos, compañías de seguros y gobiernos. Como prueba, consulte la lista de clientes para empresas que no hacen otra cosa que la "modernización" (es decir, convertir empresas de antiguos sistemas COBOL a Java / .NET, etc.), como esta .

Hay buenas razones:

  1. El cambio es más difícil en estas instituciones, principalmente por diseño (cambio rápido => errores => problemas grandes)
  2. El control de calidad a menudo es mucho más complicado, ya que atornillar incluso un error de redondeo puede causar grandes problemas.
  3. A menos que haya un incentivo monetario obvio , el status quo suele ser lo suficientemente "aceptable" como para no justificar el juego.

... y hay malas razones:

  1. Estas son típicamente instituciones grandes con grandes capas de aprobación y trámites burocráticos
  2. Menos personas realmente se preocupan

Hay varias razones posibles y varias explicaciones posibles (algunas buenas, otras malas). Difiere de banco a banco y de programador a programador por qué utilizan los sistemas que usan. Mi banco tiene actualmente un sistema de banca en línea basado en flash desde hace un año, que con todas las vulnerabilidades de seguridad apareciendo en Flash me ha puesto realmente nervioso.

Algunas cosas a tener en cuenta:

  • La mayoría de los bancos son muy viejos. Han existido desde principios de 1900, y algunos incluso antes. Es raro encontrar un banco que recién comenzó hace 5 años. Estos bancos comenzaron con sistemas de papel y lápiz, por lo que avanzan lentamente hacia la era digital. Esto está en marcado contraste con las empresas que comenzaron en Internet como Facebook.

  • Cuando trabaja en un banco, desea contratar a los programadores "mejores y más brillantes" para mantener su sistema eficiente y seguro. El problema es que las personas que poseen bancos generalmente no conocen las diferencias entre MSWord y WordPad. Por esta razón, los puestos como programadores de software bancario generalmente se ofrecen al candidato con la "mayor experiencia comercial". O, en términos del mundo real, el más antiguo. Enfrenta los hechos: a medida que te haces mayor, dejas de mantenerte al día con las tendencias modernas como AJAX. No me sorprendería si la mitad del back-end del banco estuviera codificado en Java

  • Los bancos quieren mantener las cosas simples para que "simplemente funcione". ¿Por qué crees que la energía se apaga durante las tormentas, pero el agua en el fregadero siempre funciona? Los sistemas más simples tienen menos probabilidades de fallar. Si aumenta la complejidad, aumenta la cantidad de cosas que pueden salir mal. Incluso si se trata de un sistema probado que nunca ha fallado antes, se trata de detalles adicionales y esa es una preocupación adicional.

  • Aunque mi banco realmente no puede decir nada aquí (dado que algunas computadoras no tienen Flash y ciertos iDevices ni siquiera lo permiten), muchos bancos pueden decir no al Javascript requerido simplemente porque no todos los navegadores lo admiten o es posible desactivarlo. eso. Si la Sra. Piggsworth, la bibliotecaria de 80 años de la calle, quiere acceder a su cuenta bancaria desde su Pentium I 1992, ciertamente no lo hará con nada más nuevo que Internet Explorer 3.

Además, no estoy seguro si AJAX y SSL funcionan bien. Me gustaría investigar eso.

En lo que respecta a la velocidad / eficiencia, realmente encontrará que si comenzó a usarlo, AJAX es más rápido. Solo carga los datos necesarios en lugar de páginas web enteras y puede cambiar entre marcos sin tener que realizar solicitudes HTTP. También puede hacer una interfaz más intuitiva cuando incorpora la funcionalidad de hacer clic / arrastrar y listas ordenables. El problema radica principalmente en la mayor complejidad y el miedo que eso debería traer a cualquier sistema. Cuantas más piezas tenga, más piezas que pueden salir mal.

Porque el único problema con javascript es que no tiene seguridad.

Imagínese esto, he cargado el formulario de transferencia de fondos en mi navegador. Le doy algunas entradas y el Javascript es tan bueno que calcula el total para mí antes de devolverlo.

Debido a que Javascript es un lenguaje de scripting, y puede ser editado y devuelto al servidor con / sin conocimiento del usuario (o problemas entre sitios), entonces no hay confianza en que la información regrese.

Cuando quieres artilugios sofisticados y ''cosas'', ahora estás serializando potencialmente objetos y usando Eval () para hacer cualquier cosa (te estoy mirando GWT).

Javascript tiene un buen contexto de seguridad y contención para el navegador, pero deja los datos y potencialmente el servidor muy vulnerable.

Tengo un contraejemplo para ti. Yo diría que mint.com encaja en la misma categoría que los sitios de banca por Internet, y hacen un uso intensivo de Ajax. También me atrevería a suponer que su seguridad es mejor que la mayoría de los bancos, pero no tengo ninguna prueba de eso. Los bancos simplemente "sienten" que están improvisados ​​por Consultores altamente pagados, en lugar de los desarrolladores que saben lo que están haciendo. Mint es una puesta en marcha bastante reciente, y el diseño de su sitio aún muestra el control que los desarrolladores tienen / tuvieron.

Yo diría que la razón principal es que los bancos tienden a ser tecnológicamente conservadores / ocultos. No es raro encontrar un sitio bancario que recomiende o incluso requiera el uso de IE6.