17

可能であれば、誰かが参照/証拠をリストすることはできますか？インターネットバンキングのような安全なWebアプリケーションでAJAXがあまり見られないのはなぜですか？

たとえば、インターネットバンキングには、アカウント、支払い、ツール、レポートのタブのリストがあります。通常、これらは別のページへのリンクとして実装されています。1つのページだけを作成し、AJAXを使用してさまざまなタブのコンテンツをロードできないのはなぜですか？（例：JSF RichFacesタブコントロール）

どちらのシナリオでも、さまざまなURLのブックマークと戻るボタンの処理（またはインターネットバンキングで一般的なように無効にする）が処理されると想定しています。それで、セキュリティやパフォーマンスなどにどのように影響するかなど、他のことを聞きたいですか？

私のチームは、Webベースの支払い管理システムの構築を開始しようとしています（支払いの設定、クライアントアカウントの残高の管理、調整などを考えてください）。実際の支払いは行われませんが、ある時点で大手銀行のインターネットバンキングシステムと統合されます。

1つのページを使用することと、他のすべてにAJAXを使用することに分かれています。

また

ユーザーエクスペリエンスを本当に支援する場合にのみAJAXを使用します。

4

6 に答える 6

21

Ajaxは使いやすさを向上させることができますが、複雑さが増します。

銀行にはセキュリティが必要です。

複雑さはセキュリティの敵です。

したがって、Ajaxは銀行の敵です;)

于 2010-10-06T17:55:10.147 に答える
5

反例があります。mint.comはインターネットバンキングサイトと同じカテゴリに当てはまり、Ajaxを多用していると思います。また、彼らのセキュリティはほとんどの銀行よりも優れていると推測するのは危険ですが、その証拠はありません。銀行は、彼らが何をしているのかを知っている開発者ではなく、高給のコンサルタントによって一緒に石畳にされているように「感じ」ます。Mintはかなり最近のスタートアップであり、彼らのサイトデザインは、開発者が持っている/持っていたコントロールを今でも示しています。

于 2010-10-06T18:15:36.613 に答える
2

最大の理由は、銀行は技術的に非常に保守的/隠れ家的である傾向があるということだと思います。IE6の使用を推奨または要求する銀行サイトを見つけることは珍しいことではありません。

于 2010-10-06T17:20:24.287 に答える
2

いくつかの考えられる理由といくつかの考えられる説明があります（いくつかは良い、いくつかは悪い）。銀行ごとに、またプログラマーごとに、使用するシステムを使用する理由は異なります。私の銀行には、実際には1年前の時点でフラッシュベースのオンラインバンキングシステムがあります。これにより、Flashにセキュリティの脆弱性がすべて発生し、私は非常に鋭敏になりました。

考慮すべきいくつかの事柄：

  • ほとんどの銀行は非常に古いです。それらは1900年代初頭から、そしていくつかはそれ以前から存在しています。5年前に立ち上げたばかりの銀行を見つけることはめったにありません。これらの銀行はペンと紙のシステムから始まったため、徐々にデジタル時代に突入しています。これは、Facebookのようなインターネットでスタートした企業とはまったく対照的です。

  • 銀行で働くときは、システムの効率と安全性を維持するために、「最も優秀で優秀な」プログラマーを雇いたいと考えています。問題は、銀行を所有している人々は通常、MSWordとワードパッドの違いを知らないということです。このため、銀行ソフトウェアのプログラマーとしてのポジションは、通常、「最もビジネス経験のある」候補者に提供されます。または、現実の世界では最も古いものです。事実に直面してください-あなたが年をとるにつれて、あなたはAJAXのような現代のトレンドに追いつくのをやめます。銀行のバックエンドの半分がJavaでコーディングされていても驚かないでしょう

  • 銀行は、「うまくいく」ように物事をシンプルに保ちたいと考えています。嵐の最中に停電するのに、流しの水はいつも効いているのはなぜだと思いますか？最も単純なシステムは、失敗する可能性が最も低くなります。複雑さを増すと、うまくいかない可能性のあるものの数が増えます。これまでに失敗したことのない実証済みのシステムであっても、それは余分な詳細であり、それは余分な心配です。

  • 私の銀行は実際にはここで何も言うことができませんが（一部のコンピューターはFlashを備えておらず、特定のiDeviceはそれを許可しないため）、多くの銀行は、すべてのブラウザーがFlashをサポートしていないか、無効にすることができるという理由だけで、必要なjavascriptにノーと言うかもしれませんそれ。通りを歩いている80歳の図書館員、ピッグスワース夫人が1992年のPentium Iから自分の銀行口座にアクセスしたい場合、彼女はInternetExplorer3よりも新しいものでは絶対にアクセスしません。

また、AJAXとSSLがうまく機能するかどうかはわかりません。調べてみたいと思います。

速度/効率に関する限り、実際にそれを使い始めた場合、AJAXの方が速いことがわかります。Webページ全体ではなく、必要なデータのみをロードし、HTTPリクエストを作成せずにフレームを切り替えることができます。また、クリック/ドラッグ機能と並べ替え可能なリストを組み込むと、より直感的なインターフェイスを作成できます。問題は主に、複雑さが増し、それがシステムにもたらす恐れにあります。あなたが持っているピースが多ければ多いほど、うまくいかない可能性のあるピースが多くなります。

于 2010-10-06T17:51:26.700 に答える
1

テクノロジーで常に約10年遅れているいくつかのエンティティがあります：銀行、保険会社、および政府。証拠として、このような「近代化」（つまり、企業を古いCOBOLシステムからJava / .NETに変換するなど）しか行わない企業の顧客リストを確認してください。

正当な理由があります：

  1. これらの機関では、主に設計による変更が困難です（迅速な変更=>エラー=>大きな問題）
  2. 丸め誤差でさえ失敗すると大きな問題が発生する可能性があるため、品質管理は多くの場合はるかに複雑です。
  3. 明らかな金銭的インセンティブがない限り、現状は通常、いじりを正当化しないほど十分に「許容可能」です。

...そして悪い理由があります：

  1. これらは通常、承認と官僚的形式主義の大きな層を持つ大規模な機関です
  2. 実際に気にする人は少ない
于 2010-10-06T18:13:10.527 に答える
-2

javascriptの唯一の問題は、セキュリティがないことです。

これを想像してください、私は私のブラウザに資金移動フォームをロードしました。私はそれにいくつかのエントリを与えます、そして、Javascriptは私がそれを送り返す前に私のために合計を計算するのでとても素晴らしいです。

Javascriptはスクリプト言語であり、ユーザーの知識の有無にかかわらず（またはクロスサイトの問題で）編集してサーバーに返すことができるため、戻ってくる情報の信頼はありません。

派手なウィジェットや「もの」が必要な場合は、オブジェクトをシリアル化し、Eval（）を使用して何かを実行している可能性があります（私はGWTを見ています）。

Javascriptは、ブラウザにとって優れたセキュリティコンテキストと封じ込めを備えていますが、データと潜在的にサーバーを非常に脆弱なままにします。

于 2010-10-06T18:20:15.260 に答える