4

CORSは素晴らしいものです。

特に、ドメイン名を含まないクラウドベースの CRM から呼び出される Web サービスがある場合。

しかし、それは純粋な良いですか？私は、ReST っぽい Web サービスのすべてのリソースが CORS ヘッダーを提供するようにしなければならないというプレッシャーを感じています。

CORS が私たちの設計の「穴」を露呈するのではないかと心配しています...そして私の本能は、プログラミングがスパゲッティ コードに発展しないようにするのは情報隠蔽であるということです。

リソースの CORS 化が行き過ぎた場合についての文献はありますか? （何も見つけていませんが、適切な場所を探していない可能性があります）

4

2 に答える 2

2

WhatWG によると、Access-Control-Allow-Origin: * アプリがファイアウォールの背後にない限り、使用は安全です。

リソースが Cookie または HTTP 認証に基づいて追加情報を公開する場合でも、上記のヘッダーを使用してもそれは明らかになりません。リソースは、curl や wget で既に共有されているように、XMLHttpRequest などの API と共有されます。

したがって、言い換えると、curl および wget を使用して Web に接続されたランダムなデバイスからリソースにアクセスできない場合、前述のヘッダーは含まれません。ただし、アクセスできる場合は、アクセスしてもまったく問題ありません。

私の理解では、リクエストがwithCredentialsフラグを設定して行われない限り、auth/cookie は送信されず、withCredentialsフラグが設定されている場合、リソースのワイルドカードは許可されません。

Access-Control-Allow-Originつまり、送信ドメインがホワイトリストに登録されていない場合、認証資格情報は提供されません。

于 2015-08-10T16:30:48.657 に答える
0

ソフトウェア エンジニアリング (および人生) のほとんどの場合と同様に、答えはコンテキストによって異なります。具体的には、API が何を提供しているか、誰が API にアクセスしているかというコンテキストです。

API が提供するデータの種類は何ですか? 特定のユーザーに固有のものですか？それはユーザーに敏感ですか、それとも時間に敏感ですか? 認証が必要ですか？

誰が API にアクセスしていますか? 誰でも参加できますか、それとも 1 人の個人/組織だけですか? ユーザーが API にアクセスするために使用するクライアント ライブラリは? WebブラウザやJavaScriptからのアクセスは重要ですか？

この最後の質問は最も重要です。ユーザーが Web ブラウザーからデータにアクセスする必要がない場合、CORS は API に適していない可能性があります。

X 軸に「ユーザー」、Y 軸に「データ」があり、各軸が「制限付き」から「オープン」までの範囲にあるグラフを考えてみてください。

               ^ Open
               |
               |
               |
               |
               |
USERS <------------------->
  Restricted   |        Open
               |
               |
               |
               |
               v Restricted
              DATA

データとユーザーのニーズがオープンであるほど (右上の象限)、CORS が API に適しています。ただし、これは一般的なルールに過ぎず、上記の質問に基づいて独自の API を評価する必要があります。

于 2012-12-19T03:46:35.773 に答える