2011-01-22 18 views
4

私はについて、 "Todos"チュートリアルの後に少し勉強しようとしていましたが、オンラインでは見つけられなかったいくつかの質問があります。SproutCoreのセキュリティと認証の問題

  1. SproutCoreは、すべてのビジネスロジックをクライアントに移動することになっています。どのようにそれは安全ではないのですか?悪意のあるユーザーがコードを簡単に改ざんする可能性があり(すべてがクライアント上にあるため)、アプリケーションの動作方法を変更します。どのように私はここで間違っている?
  2. SproutCoreは "DataStores"を使用し、一部はリモートにすることができます。悪意のあるユーザーがバックエンドと対話しないようにするにはどうすればよいですか?コードがクライアント側にあるので、何らかのAPIキーを使用しても機能しません。ここに何らかの種類の大会がありますか?何か案は?これは本当に私を悩ます。事前に

ありがとう!

PS:誰でも、Cappuccinoはより良い代替品だと思いますか?私はSproutCoreと一緒に行くことにしました。なぜなら、SproutCoreの方が上手くいかないものの、カプチーノのドキュメントはかなり悪いようでした。

答えて

6

イアン

あなたの懸念が有効です。つまり、どんなフレームワークであっても、すべてのクライアントサイドコードに適用されます。したがって:

Webアプリケーションは複雑なものです。クライアントへの処理の移動は、アプリケーションの応答性を向上させるので、良いことです。ただし、他のWebアプリケーションと同様に、サーバーがすべてのデータ入力を検証することが不可欠です。

さらに、すべてのWebアプリケーションは、システムセキュリティで広く使用されているよく知られている認証/認可のパラダイムを使用する必要があります。認証とは、ユーザーが自らの発言者であることを確認し、システムを使用することができることを意味します。承認とは、ユーザーが試していることをユーザーが実行できることをサーバーが確認する必要があることを意味します。新しいデータエントリを作成したり、既存のデータエントリを編集することができます。実行することが許可されていないUIオプションをユーザーに提示しないことが良い設計ですが、それに頼るべきではありません。

すべてのWebアプリケーションでこれらの処理を行う必要があります。

「バックエンドとの対話」に関する懸念:やはり、すべてのWebアプリケーションにこの懸念があります。 Firebug/Webkitを開いて、RIAが操作で使用するすべてのxhr要求を見て、そのシステムで何かをしようとするように模倣することができます。ここでも、この懸念は、実装する必要がある認証/権限チェックによって処理されます。誰でも任意のWebクライアントを使用してサーバーに要求を送信できます。その要求を検証するのは開発者次第です。

SproutCoreのDataSourceは、SCアプリケーションがサーバーとどのようにやり取りするかを抽象化したものに過ぎません。しかし、終わりにSCがやっていることは、他のRIAと同様に、XHR要求をサーバーに送信することです。

+0

クライアントとサーバー間の重複を減らすためのあらゆる努力に気付きましたか?例えば。クライアント上で行われる重要な検証は、サーバー上で繰り返さなければなりません。その検証コードを一度書くだけの簡単なメカニズムはありますか? –