JavaScript を使用して、 RESTful_ api _ に組み込まれた Flask を使用して認証を試みます。しかし、リクエストをすると、次のようなエラーが表示されます。
XMLHttpRequestは http:// myApiUrl/login をロードできません。要求されたリソースに 'Access-Control-Allow-Origin'ヘッダーがありません。したがって、起点 'null'はアクセスを許可されていません。
APIまたはリモートリソースがヘッダーを設定する必要があることはわかっていますが、Chrome拡張機能 Postman を使用してリクエストを行ったときに、なぜそれが機能したのですか。
これはリクエストコードです:
$.ajax({
type: "POST",
dataType: 'text',
url: api,
username: 'user',
password: 'pass',
crossDomain : true,
xhrFields: {
withCredentials: true
}
})
.done(function( data ) {
console.log("done");
})
.fail( function(xhr, textStatus, errorThrown) {
alert(xhr.responseText);
alert(textStatus);
});
私が正しく理解していれば、あなたは XMLHttpRequest をあなたのページが表示されているのとは異なるドメインに対してやっている。セキュリティ上の理由から、通常同じブラウザでリクエストを許可しているため、ブラウザはそれをブロックしています。クロスドメインリクエストを行う場合は、別のことをする必要があります。その実現方法に関するチュートリアルはCORSの使用です。
あなたが郵便配達員を使用しているとき、彼らはこの方針によって制限されません。から引用されたクロスオリジンXMLHttpRequest:
通常のWebページはXMLHttpRequestオブジェクトを使用してリモートサーバーとデータを送受信できますが、それらは同じOriginポリシーによって制限されています。拡張子はそれほど制限されていません。エクステンションは、オリジンを越えたアクセス許可を最初に要求している限り、オリジンの外部にあるリモートサーバーと通信できます。
これは本番環境やクライアントにアプリケーションを見せる必要がある場合の修正ではありません。これはUIとバックエンド development が異なる servers にあり、本番環境では実際にオンになっている場合にのみ役立ちます。同じサーバー例:ローカルでテストする必要がある場合にバックエンドサーバーを指定する必要がある場合は、任意のアプリケーションのUIを開発しますが、そのシナリオではこれは完璧な修正です。製品版では、クロスオリジンアクセスを許可するためにCORSヘッダをバックエンドサーバに追加する必要があります。
簡単な方法は、CORSを使用してアクセスできるようにGoogle Chromeで拡張子を追加することです。
No 'access-control-allow-Origin' ヘッダー要求へのアクセスを許可するときはいつでも、この拡張子を有効にしてください。
または
Windowsでは、このコマンドを run windowに貼り付けます。
chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security
これにより、新しい chrome ブラウザが開き、no 'access-control-allow-Origin' ヘッダー要求へのアクセスが許可されます。
_ php _ を使用している場合は解決するのがとても簡単です。リクエストを処理するPHPページの先頭に次のスクリプトを追加するだけです。
<?php header('Access-Control-Allow-Origin: *'); ?>
警告: これにはあなたのPHPファイルがセキュリティの問題であることが含まれています。あなたはこの攻撃に対するあなたのファイル/サービスを防ぐために認証のためにセッションとクッキーを使わなければなりません。あなたのサービスは クロスサイトリクエストフォージェリ (CSRF)の脆弱性があります。
Node-red を使用している場合は、次の行のコメントを外してnode-red/settings.js
ファイルでCORSを許可する必要があります。
// The following property can be used to configure cross-Origin resource sharing
// in the HTTP nodes.
// See https://github.com/troygoode/node-cors#configuration-options for
// details on its contents. The following is a basic permissive set of options:
httpNodeCors: {
Origin: "*",
methods: "GET,PUT,POST,DELETE"
},
誰かがこのサイトをずっと前に私と共有してくれたらいいのに http://cors.io/ 私のプロキシを作ったり信頼したりするのに比べて、1時間も節約できただろう。ただし、運用に移行するときは、データのあらゆる側面を管理するため、独自のプロキシを用意することが最善の策です。
必要なものすべて
https://cors.io/?http://HTTP_YOUR_LINK_HERE
Node.js を使用している場合は、試してください。
app.use(function(req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
next();
});
より詳しい情報:ExpressJS上のCORS
Ajaxを使ったクロスドメインの問題があります。ブラウザがhttp://
パス経由でアクセスするときに別のドメインと見なすwww.
なしで同じhttp://www.
パス上のファイルにアクセスしている(またはwww.
からアクセスしてwww.
を含む同じパスに投稿している)ことを確認する必要があります。です。あなたは別のドメインに投稿しようとしており、Originの問題のためにブラウザがフローをブロックしています。
_ api _ が要求元のホストと同じホストに配置されていない場合、フローはブロックされ、APIと通信するための別の方法を見つける必要があります。
なぜなら
$ .ajax({type: "POST" - 呼び出し _ options _
$ .post( - 呼び出し _ post _
どちらもPostmanが適切に "POST"を呼び出しますが、呼び出したときは "OPTIONS"になります。
C#Webサービスの場合 - webapi
次のコードを<system.webServer>タグの下のweb.configファイルに追加してください。これはうまくいくでしょう
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
あなたがajax呼び出しで何か間違いをしていないことを確認してください
jQuery
$.ajax({
url: 'http://mysite.Microsoft.sample.xyz.com/api/mycall',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
type: "POST", /* or type:"GET" or type:"PUT" */
dataType: "json",
data: {
},
success: function (result) {
console.log(result);
},
error: function () {
console.log("error");
}
});
Angular 4号を参照してください。 http://www.hubfly.com/blog/solutions/how-to-fix-angular-4-api-call-issues/ /
注: あなたがコンテンツをダウンロードするのを探しているなら 第三者のウェブサイトから then これはあなたを助けてくれないでしょう 次のコードを試すことはできますが、JavaScriptはできません。
System.Net.WebClient wc = new System.Net.WebClient();
string str = wc.DownloadString("http://mysite.Microsoft.sample.xyz.com/api/mycall");
あなたがしたくない場合:
そしてあなたはあなたのサーバーがその時CORSを有効にしていると確信しています(ここでCORSをテストしてください: http://www.test-cors.org/ )
それからあなたはあなたの要求と共にOriginパラメータを渡す必要があります。このOriginはあなたのブラウザがあなたの要求と共に送るOriginと一致しなければなりません。
ここでそれを実際に見ることができます。 http://www.wikinomad.com/app/detail/Campgrounds/3591
編集機能は、データをフェッチするためにGET&POST要求を別のドメインに送信します。この問題を解決するためにOriginパラメータを設定しました。バックエンドはmediaWikiエンジンです。
tldr:呼び出しに "Origin"パラメータを追加します。これは、ブラウザが送信するOriginパラメータである必要があります(Originパラメータを偽造することはできません)。
AngularJSを使用して自分のAPIにアクセスしたときに問題が発生しました。 SoapUI 5.0とColdFusionでも同じ要求が機能しました。私のGETメソッドはすでにAccess-Control-Allow-Originヘッダを持っていました。
AngularJSが "トライアル" OPTIONSリクエストを行うことを知りました 。 ColdFusionでは、デフォルトでOPTIONSメソッドが生成されますが、特にこれらのヘッダーは多くありません。このエラーは、そのOPTIONS呼び出しに対する応答として生成されたものであり、私が意図的にGETを呼び出したためのものではありません。下記のOPTIONSメソッドを私のAPIに追加した後、問題は解決しました。
<cffunction name="optionsMethod" access="remote" output="false" returntype="any" httpmethod="OPTIONS" description="Method to respond to AngularJS trial call">
<cfheader name="Access-Control-Allow-Headers" value="Content-Type,x-requested-with,Authorization,Access-Control-Allow-Origin">
<cfheader name="Access-Control-Allow-Methods" value="GET,OPTIONS">
<cfheader name="Access-Control-Allow-Origin" value="*">
<cfheader name="Access-Control-Max-Age" value="360">
</cffunction>
サーバーからの応答を要求すると、次のように設定されていて同じエラーが発生しました。
サーバー側: SparkJava - >はREST-APIを提供します
クライアント側: ExtJs6 - >ブラウザのレンダリングを提供
サーバー側 私はこれをレスポンスに追加しなければなりませんでした:
Spark.get("/someRestCallToSpark", (req, res) -> {
res.header("Access-Control-Allow-Origin", "*"); //important, otherwise its not working
return "some text";
});
クライアント側 リクエストにこれをaddしなければなりませんでした:
Ext.Ajax.request({
url: "http://localhost:4567/someRestCallToSpark",
useDefaultXhrHeader: false, //important, otherwise its not working
success: function(response, opts) {console.log("success")},
failure: function(response, opts) {console.log("failure")}
});
https://github.com/Rob--W/cors-anywhere/ は、独自のCORSプロキシをセットアップして実行するために使用できる(Node.js)コードを提供します。積極的に維持されており、正しいAccess-Control-*
応答ヘッダーの基本的な送信だけでなく、プロキシの動作を制御するための多くの機能を提供します。
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS には、ブラウザがクライアントサイドWebアプリケーションがJavaScriptから作成するクロスオリジンリクエストを処理する方法を説明する詳細があります可能であれば、リクエストが行われるサーバーによる送信を設定する必要があるヘッダー。
リクエストを行い、レスポンスを取得する必要があるサイトがAccess-Control-Allow-Origin
レスポンスヘッダーを返さない場合、ブラウザはalwaysクライアント側のJavaScriptコードによって直接行われたクロスオリジンリクエストをブロックします。したがって、サイトがあなたが制御するものではなく、動作を構成できる場合、willが機能するのは、リクエストをプロキシすることだけです自分で実行する、またはオープンプロキシを介して実行する独自のプロキシ。
ここの他のコメントで述べたように、リクエストでオープンプロキシを信頼しないのには十分な理由があります。つまり、自分が何をしているかを知っていて、オープンプロキシがニーズに合っていると判断した場合、 https://cors-anywhere.herokuapp.com/ は確実に利用でき、アクティブに維持され、それは https://github.com/Rob--W/cors-anywhere/ コードのインスタンスを実行します。
ここで述べた他のオープンプロキシ(少なくともいくつかはもう利用できないようです)と同様に、クライアントコードがhttp://foo.com
などに直接リクエストを送信する代わりに動作しますhttps://cors-anywhere.herokuapp.com/http://foo.com
に送信すると、プロキシは必要なAccess-Control-*
ヘッダーをブラウザーに表示される応答に追加します。
shrutiの回答 に基づいて、私は必要な引数を使用してChromeブラウザのショートカットを作成しました:
YQLを使ってYahooのサーバーを介してリクエストをプロキシすることで問題を回避できます。ほんの数行のコードです。
var yql_url = 'https://query.yahooapis.com/v1/public/yql';
var url = 'your api url';
$.ajax({
'url': yql_url,
'data': {
'q': 'SELECT * FROM json WHERE url="'+url+'"',
'format': 'json',
'jsonCompat': 'new',
},
'dataType': 'jsonp',
'success': function(response) {
console.log(response);
},
});
これが説明付きのリンクです。 https://vverma.net/fetch-any-json-using-jsonp-and-yql.html
Entity Framework を使用している場合、CORS
を有効にしていてもこのエラーが発生することがあります。私はエラーがクエリの未完成のファイナライズが原因で発生したと考えました。私はこれが同じ状況で他の人を助けることを願っています。
次のコードはXMLHttpRequest cannot load http://myApiUrl/login. No 'Access-Control-Allow-Origin' header is present on the requested resource.
エラーをスローする可能性があります。
using (DBContext db = new DBContext())
{
return db.Customers.Select(x => new
{
Name = x.Name,
CustomerId = x.CustomerId,
});
}
これを修正するには、クエリの最後に.ToList()
や.FirstOrDefault()
のようなファイナライズコールが必要です。
using (DBContext db = new DBContext())
{
return db.Customers.Select(x => new
{
Name = x.Name,
CustomerId = x.CustomerId,
}).ToList();
}
私の場合はJEE7 JAX-RSアプリケーションを使用していましたが、以下のトリックは完璧に機能しました。
@GET
@Path("{id}")
public Response getEventData(@PathParam("id") String id) throws FileNotFoundException {
InputStream inputStream = getClass().getClassLoader().getResourceAsStream("/eventdata/" + id + ".json");
JsonReader jsonReader = Json.createReader(inputStream);
return Response.ok(jsonReader.readObject()).header("Access-Control-Allow-Origin", "*").build();
}
ブラウザからこのエラーメッセージが表示されたら:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '…' is therefore not allowed access
あなたがコントロールできないリモートサーバーへのAjax POST/GETリクエストをやろうとしているとき、この簡単な修正を忘れてください:
<?php header('Access-Control-Allow-Origin: *'); ?>
あなたが本当に必要なのは、Ajaxリクエストを実行するためにJavaScriptを使う場合、特にあなたのクエリを受け取ってそれをリモートサーバに送る内部プロキシだからです。
まずJavaScriptコードで、自分のサーバーにAjax呼び出しを行います。
$.ajax({
url: yourserver.com/controller/proxy.php,
async: false,
type: "POST",
dataType: "json",
data: data,
success: function (result) {
JSON.parse(result);
},
error: function (xhr, ajaxOptions, thrownError) {
console.log(xhr);
}
});
次に、proxy.phpという単純なPHPファイルを作成して、POSTデータをラップし、それらをパラメータとしてリモートURLサーバーに追加します。 Expedia Hotelの検索APIを使用してこの問題を回避する方法の例を示します。
if (isset($_POST)) {
$apiKey = $_POST['apiKey'];
$cid = $_POST['cid'];
$minorRev = 99;
$url = 'http://api.ean.com/ean-services/rs/hotel/v3/list?' . 'cid='. $cid . '&' . 'minorRev=' . $minorRev . '&' . 'apiKey=' . $apiKey;
echo json_encode(file_get_contents($url));
}
することによって:
echo json_encode(file_get_contents($url));
あなたはただ同じ問い合わせをしているのですが、サーバー側でそれ以降、それはうまく動くはずです。
NizarBsbからコピーして貼り付けた回答
私はhtaccessを使って(私の場合はフォントのために)解決することに成功したが、明らかに、OPは少し違って尋ねている。しかし、FileMatchパターンを使用してクロスエラーを発生させないように任意の種類の拡張子を追加することができます。
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
GoLang APIの場合:
最初に MDN CORS Doc を見て、CORSとは何かを知ることができます。私の知る限り、CORSは、リクエストの発信元がサーバーリソースにアクセスすることを許可するかどうかに関するものです。
また、サーバーレスポンスのHeader
でAccess-Control-Allow-Origin
を設定することにより、Originがサーバーにアクセスできるリクエストを制限できます。
たとえば、サーバーレスポンスで次のヘッダーを設定すると、http://foo.example
から送信されたリクエストのみがサーバーにアクセスできます。
Access-Control-Allow-Origin: http://foo.example
そして、以下は、任意のオリジン(またはドメイン)から送信されたリクエストを許可します:
Access-Control-Allow-Origin: *
そして、私がエラーメッセージで知っているように、requested resource
はサーバーのリソースを意味するので、No 'Access-Control-Allow-Origin' header is present on the requested resource.
はサーバー応答にAccess-Control-Allow-Origin
ヘッダーを設定しなかったことを意味します。リクエストはAccess-Control-Allow-Origin
にリストされていないため、リクエストはアクセスを許可されていません。
要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません。したがって、Origin 'null'はアクセスを許可されません。
GoLangでは、gorilla/mux
パッケージを使用してlocalhost:9091
でAPIサーバーを構築し、応答ヘッダーに"Access-Control-Allow-Origin", "*"
を追加してCORSを許可します。
func main() { // API Server Code
router := mux.NewRouter()
// API route is /people,
//Methods("GET", "OPTIONS") means it support GET, OPTIONS
router.HandleFunc("/people", GetPeople).Methods("GET", "OPTIONS")
log.Fatal(http.ListenAndServe(":9091", router))
}
// Method of '/people' route
func GetPeople(w http.ResponseWriter, r *http.Request) {
// Allow CORS by setting * in sever response
w.Header().Set("Access-Control-Allow-Origin", "*")
w.Header().Set("Access-Control-Allow-Headers", "Content-Type")
json.NewEncoder(w).Encode("OKOK")
}
そして、クライアントでJavaScriptを使用します。localhost:9092
でChromeによるリクエストを行うと、サーバーlocalhost:9091
から「OKOK」を正常に取得できます。
function GetPeople() {
try {
var xhttp = new XMLHttpRequest();
xhttp.open("GET", "http://localhost:9091/people", false);
xhttp.setRequestHeader("Content-type", "text/html");
xhttp.send();
var response = JSON.parse(xhttp.response);
alert(xhttp.response);
}
catch (error) {
alert(error.message);
}
}
また、Fiddler
などのツールを使用して、要求/応答ヘッダーを確認できます。
よくある質問 - これまで読んだことがあって他に何も助けになっていない場合に検討する必要があるもう1つのこと。 Akamai、LimelightなどのCDNを所有している場合は、リソースのURIについて自分が持っているキャッシュキーを確認します。 Originのヘッダ値が含まれていない場合は、他のOriginからリクエストされたときにキャッシュされたレスポンスを返す可能性があります。これをデバッグするのにちょうど半日を費やしました。 CDN設定が更新され、私たちのドメインであるいくつかの選択したドメインのOriginの値のみが含まれ、それ以外のドメインではnullに設定されるようになりました。これはうまくいっているようで、私たちの知られているドメインのブラウザが私たちのリソースを見ることを可能にします。確かに他のすべての答えはここに着くための前提条件ですが、CDNがあなたのブラウザからの最初のホップであるならば、これは検討するべき何かです。
私達の場合、私達は私達のサービスにそれをしているいくつかの要求を見ることができたが、そのサイトが送っていた量にはほとんど及ばなかった。それは私達をCDNに向けさせました。元のリクエストがブラウザAJAXコールの一部ではなく直接リクエストから提供され、レスポンスヘッダーAccess-Control-Allow-Originが含まれていないことを確認しました。どうやらCDNはこの値をキャッシュしました。 Akamai CDNの設定Originのリクエストヘッダの値を一致の一部と見なすように微調整した結果、機能したようです。
これは、JavaScriptから私のphp apiまで、何度も起こります。これは、いくつかの理由の1つです。 私は<?php header('Access-Control-Allow-Origin: *'); ?
を一つにするのを忘れています。これはクロスドメインアクセスに役立ちます。もう1つの理由は、jQueryのajaxリクエストで、特定のdataTypeを指定して別のdataTypeを返すため、エラーが発生することです。
このエラーの最後で最も顕著な推論は、要求しているページに解析エラーがあることです。ブラウザでそのページのURLにアクセスした場合、おそらく解析エラーが表示され、問題に対処するための行番号が表示されます。
これが誰かに役立つことを願っています。これをデバッグするのに毎回時間がかかりました。確認することのチェックリストがあればいいのにと思います。
Jsonp requestでは、 "jsonpCallback"をキャッチして送り返す必要があります。
$.ajax({
url: lnk,
type: 'GET',
crossDomain: true,
dataType: 'jsonp',
success: function (ip) { console.log(ip.ip); },
error: function (err) { console.log(err) }
});
バックエンド側(バックエンドPHPとして使用している場合)
echo $_GET['callback'].'({"ip":"192.168.1.1"})';
この場合、バックエンドの応答は以下のようになります。
jQuery331009526199802841284_1533646326884({"ip": "192.168.1.1"})
しかし、フロントエンドで "jsonpCallback"を手動で設定してバックエンド側で捕まえることができます。
$.ajax({
url: lnk,
type: 'GET',
crossDomain: true,
dataType: 'jsonp',
jsonpCallback: 'get_ip',
success: function (ip) { console.log(ip.ip); },
error: function (err) { console.log(err) }
});
この場合、バックエンドの応答は以下のようになります。
get_ip({"ip": "192.168.1.1"})
私のウェブサイト(.NETベース)でこれを追加しました。
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
</customHeaders>
</httpProtocol>
</system.webServer>
this videoに感謝します。
フロントエンドではなくバックエンド(Flask内)でこれを修正したい場合は、Flask CORS pythonパッケージをお勧めします。 フラスコの芯
App.pyに1行の簡単な行を追加すれば、Originのヘッダを許可する標準を自動的に挿入したり、必要に応じてカスタマイズしたりできます。
完全を期すために、 Apache はcorsを許可します。
Header set Access-Control-Allow-Origin "http://www.allowonlyfromthisurl.com"
Header set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header set Access-Control-Max-Age "1000"
Header set Access-Control-Allow-Headers "x-requested-with, Content-Type, Accept-Encoding, Accept-Language, Cookie, Referer"
CORSはあなたのためです。
CORSは「クロスオリジンリソース共有」であり、クロスドメインリクエストを送信する方法です。現在、XMLHttpRequest2とFetch APIはどちらもCORSをサポートしています。
しかしそれには限界があります。サーバーは Access-Control-Allow-Origin を具体的に要求する必要があり、 '*'に設定することはできません。
また、Originからリクエストを送信できるようにするには、JSONPが必要です( Access-Control-Allow-Origin も設定する必要がありますが、 '*'にすることもできます)。
何を選ぶべきかわからない場合の多くの要求方法のために、私はあなたがそれをするために完全に機能的なコンポーネントが必要であると思います。単純なコンポーネントcattaを紹介しましょう。
最新のブラウザ(> Internet Explorer 9、Chrome、Firefox、Edgeなど)を使用している場合は、シンプルだが美しいコンポーネントを使用することを強くお勧めします。https://github.com/Joker-ゼリー/カッタ。依存関係はなく、3 KB未満です。また、Fetch、Ajax、およびJSONPを同じデッドシンプル構文およびオプションでサポートしています。
catta('./data/simple.json').then(function (res) {
console.log(res);
});
ES6モジュール、CommonJS、さらにはHTMLの<script>
のように、プロジェクトへのインポートのすべての方法もサポートします。
これらの答えのほとんどは、自分が管理しているサーバーにCORSヘッダーを追加する方法をユーザーに伝えます。
ただし、Webページで制御していないサーバーからのデータが必要な場合、1つの解決策は、ページ上にscriptタグを作成し、src属性をCORSヘッダーを持たないAPIエンドポイントに設定してからそのデータをロードすることです。ページ上に:
window.handleData = function(data) {
console.log(data)
};
var script = document.createElement('script');
script.setAttribute('src','https://some.api/without/cors/headers.com&callback=handleData');
document.body.appendChild(script);
Angularの$http.get
でこのエラーが出ました。代わりに$http.jsonp
を使う必要がありました。
多少複雑かもしれませんが、リクエストをルーティングするためにWebサーバーを使用することができます。私はnode jsのエキスパートではありません。だから私はこれがきれいなコードであるかどうかわからない。
しかしこれは私のために働く
これはちょっとした例です。
NODE JS
var rp = require('request-promise');
var express = require('express'),
app = express(),
port = process.env.PORT || 3000;
var options = {
method: 'POST',
uri: 'http://api.posttestserver.com/post',
body: {
some: 'payload'
},
json: true // Automatically stringifies the body to JSON
};
app.get('/', function (req, res) {
rp(options)
.then(function (parsedBody) {
res.send(parsedBody)
})
.catch(function (err) {
res.send(err)
});
});
app.listen(port);
_ js _
axios.get("http://localhost:3000/").then((res)=>{
console.log('================res====================');
console.log(res);
console.log('====================================');
})
サーバーがSpring Boot Appの場合、レストのコントローラーの一番上にこの注釈を追加してください-@CrossOrigin
これで動作するはずです。ありがとう
application_controller.rb
内のRuby on Railsサーバーの場合、これを追加します。
after_action :cors_set_access_control_headers
def cors_set_access_control_headers
headers['Access-Control-Allow-Origin'] = '*'
headers['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS'
headers['Access-Control-Allow-Headers'] = '*'
end
要求されたリソースに 'Access-Control-Allow-Origin'ヘッダーがありません。オリジン ' https://sx.xyz.com 'はアクセスを許可されていません。
私は、AjaxレスポンスでCross Domain Data Exchangeに関する同様の問題に error undefined として直面していました。しかし、ヘッダの応答は ステータスコード:200 OK
Failed to load https://www.Domain.in/index.php?route=api/synchronization/checkapikey:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'https://sx.xyz.in' is therefore not allowed access.
それを回避するための解決策: 私の場合は、Ajaxを介して関数checkapikey()を別のドメインに呼び出し、呼び出しが行われた場所にデータを含む応答を取得することでした。
if (($this->request->server['REQUEST_METHOD'] == 'POST') && isset($this->request->server['HTTP_Origin'])) {
$this->response->addHeader('Access-Control-Allow-Origin: ' . $this->request->server['HTTP_Origin']);
$this->response->addHeader('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS');
$this->response->addHeader('Access-Control-Max-Age: 1000');
$this->response->addHeader('Access-Control-Allow-Credentials: true');
$this->response->addHeader('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With');
$headers = getallheaders();
...
}
この解決策は間違いなくあなたのために働くでしょう。カスタムメッセージハンドルを追加する
public class CustomHeaderHandler : DelegatingHandler
{
protected override async Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request, CancellationToken cancellationToken)
{
HttpResponseMessage response = await base.SendAsync(request, cancellationToken);
var referrer = request.Headers.Referrer;
if (referrer != null && !response.Headers.Contains("Access-Control-Allow-Origin"))
{
response.Headers.Add("Access-Control-Allow-Origin", referrer.Scheme + "://" + referrer.Authority);
}
return response;
}
}
Webapiconfig.csに登録してください。
config.MessageHandlers.Add(new CustomHeaderHandler());
SignalRを使用している場合は、このコードをgloble.asax.csファイルに追加します。
protected void Application_BeginRequest(object sender, EventArgs e)
{
var referrer = Request.UrlReferrer;
if (Context.Request.Path.Contains("signalr/") && referrer != null)
{
Context.Response.AppendHeader("Access-Control-Allow-Origin", referrer.Scheme + "://" + referrer.Authority);
}
}
Opera( Chrome と同じように動作します)の場合、私は次のコマンドでブラウザを起動しました。
opera --user-data-dir="~/Downloads/opera-session" --disable-web-security
問題は解決しました!今、私は(私のハードディスクドライブ上の)ローカルのHTMLファイルで作業し、同じファイル内のリモートの起点にAjaxリクエストを呼び出すことができます。
注1:ホームディレクトリ内の任意のフォルダを--user-data-dirとして指定できます。
注2:テスト済みの Debian 8 (Jessie)/ Opera 39
(上記のパラメータなしで)正常に起動すると、同じ要求がエラーコードブロックに入ります。
おそらく、本番サーバーから開発サーバーにリソースをコピーし、そのリソースへのURLを動的に調整することができます。そのようにして、あなたはいつも同じOriginから読むことになり、Origin間の例外を排除します。
私がサービスとしてスプリングブートを使用していた私の場合は、責任ある操作にuse cross Originアノテーションを追加することができます。
@CrossOrigin(origins = "http://localhost:4200")
@RequestMapping(value = "getFoo", method = RequestMethod.GET)
public ResponseEntity getFoo(){
// do something
}
私は自分のドメイン内に、外部ドメインからコンテンツを取得して表示する単純なブリッジを作成しました。
<?php
header("Content-Type: text/plain");
if (isset($_GET["cnic"]))
{
$page = file_get_contents("https://external.domain.com/api/verify/" . $_GET["cnic"]);
echo $page;
}
else
{
echo "";
}
?>
さて、AJAXの外部ドメインにアクセスする代わりに、このブリッジファイルのURLを配置しました。
必要に応じてContent-Type
を調整してください。データがJSON形式の場合はheader("Content-Type: application/json");
を使用してください。
それを「迂回」する別の方法 - AJAX proxyを言及するだけで。別のOriginからデータを取得してリクエストをあなたに送り返すためにリクエストをあなたのサーバーに送信してください。
セキュリティ上の問題がある可能性があるため、JSONPよりもこのアプローチをお勧めします。
Web APIにアクセスするクライアントURLに対してCORSを有効にすることでこれを解決しました。
例えば:
[EnableCors(origins: "http://clientaccessingapi.com", headers: "*", methods: "*")]