MarkLogic CORSヘッダー

別のホストまたはポートからのAJAX要求を使用してMarkLogic RESTエンドポイントに接続する場合は、CORLogicを回避するためにMarkLogicが組み込みRESTエンドポイントにヘッダーを追加することはできません問題？MarkLogic CORSヘッダー

私はXQueryのスクリプトを使用して、これに接続することにより、これを回避できると信じて - およびXQueryスクリプトに以下を追加：

xdmp:add-response-header("Access-Control-Allow-Origin", "*"); 
xdmp:add-response-header("Access-Control-Allow-Headers", "origin, x-requested-with, content-type");

だから、例えば"v1/documents？uri ="エンドポイントに接続するのではなく、同じ機能を提供する "documents.xqy？uri ="スクリプトに接続するだけでした。このアプローチには欠点がありますか？これを処理するより良い方法はありますか？

過去に与えられた別のオプションは、リバースプロキシを使用することでしたが、これは上記のアプローチを考えれば必要ないと思いますか？

ありがとうございます！

出典

2017-02-09 Robert

REST APIを使用する代わりにカスタムXQueryエンドポイントを作成する場合は、応答ヘッダーを設定することができます。唯一の欠点は、REST APIのすぐに使用できる機能を失うことです。

もう1つの方法は、クライアント側のJavaScriptとMarkLogicの中間層を使用し、そこでCORSの問題を処理する方法です。

あなたがしたくないことは、client-side JavaScript talk directly to the REST APIです。これは、ODBC接続が一般に公開されているようなものです。（概念実証のためにそれを行うのは良いことだが、生産のための良い考えではない。）

出典

2017-02-09 16:46:23

私はDaveの主張を2番目にしている。「MarkLogic REST APIは、3層アーキテクチャーを念頭に置いて構築されました。中間層は、ビジネスロジックを適用して適切な要求のみを処理するようにしています。 REST API」を参照してください。きめ細かで強力なREST APIエンドポイントではなく、パブリックネットワーク上のビジネスロジック定義のエンドポイントだけを公開します。 –

ありがとう！これは、MarklogicでLDAP認証を使用するプライベートネットワークで使用するためのものです。 Daveの記事に記載されている懸念事項は、このユースケースではあまり心配されていませんか？また、CORSの問題を回避するための1つのオプションは、関連するヘッダーを追加できるようにREST APIを拡張することです。すでに説明したように、xqueryスクリプトに接続してヘッダーを追加する方法を使用しています。 REST APIを拡張する上でこれを行うことには不利な点がありますか、それともユースケースに依存していますか？ – Robert

プライベートネットワークで使用すると、許可を超えて行動しようとする可能性のある人の数は減りますが、問題自体は変更されません。 2層アプリケーション（完全に合理的なアーキテクチャ）に取り組んでいる場合は、エンドポイントをロールして、人々ができることを細かく制御できるようにすることがアドバイスです。 –

答えて

関連する問題