問題タブ [3scale]

3Scale の API 管理を使用する nodejs を使用してプロトタイプ API をセットアップしようとしています。

次のようなプラグイン統合コードを見つけることができました。

サーバーモジュールの一部として、これは私には理にかなっています。しかし、クライアントの資格情報がその方程式のどこにあるのかわかりません....

クライアントがあなたのアプリを指しているように見えます。ここにアプリのパスワードがあります...しかし、実際のクライアントのユーザー名/パスワードはどうですか!? それはどこでチェックされますか？

私は彼らのアーキテクチャを把握していないように感じます (これは私の最初の実際のノード プロジェクトであり、間違いなく 3Scale を使用するのが初めてであるためです)...

さらに、クライアントの要求はどのように見えるでしょうか?

Mashery、WSO2、3scaleの違いを知りたいです。以前に API Manager を使用したことがある人は、意見を述べることができますか? それぞれのメリットとデメリットとは

ありがとう

乾杯

キー/シークレットの組み合わせを介してアクセスを許可する歴史的な API を使用しています。元の API 設計者が指定したものは、HTTP 基本認証ヘッダーでユーザー名とパスワードとして渡す必要があります。

私たちの API クライアントベースが拡大しつつある今、3scaleを使用して認証、レート制限、およびその他の機能の両方を処理することを検討しています。3scale の指示とアドバイスに従って、API サーバーの前で Nginx プロキシを使用します。これは、3scale のサービスに対して認証を行い、すべてのアクセス制御システムを処理します。

既存のクライアントのキーとシークレットを 3scale にエクスポートし、2 つのシステムの同期を維持します。返されるデータの一部はクライアント固有であるため、既存のアプリが引き続き既存の方法でキーとシークレットを受信する必要があります。ただし、3scale が認証方法としてネイティブにサポートしていない HTTP 基本認証リクエストを、書き換えられたカスタム ヘッダーに変換する方法を見つける必要があります。

3scale が構成する Nginx および Lua 構成を使用して、プロキシをセットアップできました。これにより、-u key:secretがサーバーに渡され、正しく処理されます。ただし、現時点では、3scale がアクセスを管理できるように、同じ認証情報をクエリ パラメーターまたはカスタム ヘッダーとして追加する必要があります。Nginx プロキシにそれを処理してもらいたいので、ユーザーは既存の方法で 1 セットの認証詳細を提供し、3scale もそれを取得できます。

Ruby などの私が知っている言語では、HTTP_AUTHORIZATION ヘッダーをデコードし、Base64 でエンコードされた部分を取り出してデコードし、提供されたキーとシークレットのコンポーネントを見つけることができます。しかし、私はNginxの初心者であり、Nginx内で同じことを達成する方法がわかりません（また、3scaleが提供するLuaスクリプトがソリューションの一部になる可能性があるかどうかもわかりません）...

スタックに3scaleを実装する方法を実証するために、概念実証を行っています。1 つの例では、POST要求本文の操作を行って、従来の API 形式を新しい内部形式にマップする API ファサードを作成したいと考えています。例えば。のようなものを変更します

の中へ

content_by_luaのLua モジュール ドキュメント。これは、適切なメソッドのようです。

このディレクティブと他のコンテンツ ハンドラー ディレクティブを同じ場所で使用しないでください。たとえば、このディレクティブとproxy_passディレクティブを同じ場所で使用しないでください。

私の理解では、content_by_lua は proxy_pass のようなコンテンツ ハンドラであり、場所ごとに 1 つしか使用できません。

それがプロキシの仕組みの基礎であるため、 proxy_passを削除する方法はないと思います。別の場所でリクエストをキャプチャし、 content_by_luaを使用してから、 proxy_passを実装する場所に渡すか、次のような別の方法がありますどちらがより適切なrewrite_by_lua ?

他の人に役立つ場合は、次の関数 (Lua の最初のビット) を追加しました。これは、user_key3scale が承認に必要とするパラメーターを削除しますが、転送された場合に API に対して無効になります。

Ubuntu ゲスト OS を搭載した Ubuntu マシンを使用しています。ゲスト OS で OpenDaylight コントローラーを実行し、Mininet でトポロジーを作成し、それらを localhost:8080 の OpenDaylight GUI で表示しました。次に、Chrome ブラウザーで Postman REST API クライアント拡張機能を使用して、ODL コントローラーに GET 要求を行いました。

ローカルホスト:8080/restconf/運用/opendaylight-inventory:nodes/

XML形式で適切な応答が得られました。ここで、リクエストを NGINX プロキシ経由で 3Scale に渡し、app_id および app_key パラメーターを使用して認証を取得する必要があります。次に、適切な応答を取得できるように、要求が ODL コントローラーに転送されます。

NGINX からプロキシ構成ファイルを既にダウンロードしています。これらのファイルにどのような変更を加える必要がありますか? 以前と同じ応答を得るには、Postman クライアントに入力する要求は何ですか?

API LM は初めてで、apigee、3scale、mashery、mulesoft、TIBCO APIX などのツールを使用した API の構築について混乱しています。

ここ数年、API はすべて、ビジネス上の問題を解決するためにコード/アプリケーションを作成/構築するために使用する言語の API または SDK に関するものであることを知っています。Java API や J2EE API などと言う

アプリケーション/システムを使用して独自のデータサービスを構築し、それをサービス (WS/REST) として公開し、上記のツール (apigee、3scale、mashery、mulesoft ec) を使用する必要がありますか、それともこれらのツールを使用して開発者が API を構築できるようにする必要がありますか?スクラッチ？

つまり、企業内に独自のアプリケーション (Java ベース、DB、.Net サービス、または weblogic でホストされる Web アプリケーション) を作成し、それを B2D または DX の API として (認証、分析、ポータル、開発者アクセス) は「API のビルド」と呼ばれますか?

openrestyクックブックをインストールしましたが、今度は構成ファイルをインストールする必要があります。Chef を使用して nginx.conf および nginx.lua ファイルを追加する最良の方法は何ですか?

3scale から提供された lua ファイルを変更しようとしています。次のエラーが発生し続けます。

そして、このエラーにつながるコードのブロックは次のとおりです。

エラーが発生しないngx.var.access_token = params.access_token .. ":" .. params.user_id後に配置すると。get_credentials_access_token(params, service_ID)この動作の原因は何ですか?

編集:
元のファイルはhttps://github.com/3scale/nginx-oauth-templates/blob/master/oauth2/implicit-flow/token-generation/nginx.luaにあります。

現在、API は .net (webapi) の Swashbuckle でドキュメント化されています。このドキュメントを 3scale ActiveDocs にインポートする方法はありますか?

前もって感謝します

Websocket アプリケーション用の API ゲートウェイが必要です。

1. 特定の IP からの異常なリクエストを分析して特定する
2. クォータとレート制限
3. 統計学
4. 無料または商用
5. 確かな性能

私の WebSocket のサブ プロトコルは WAMP です。

私はそれを開発するつもりであり、次のように機能すると思います。

• クライアント アプリケーションと WebSocket サーバーの間にプロキシ (NGINX または HAProxy) がインストールされている
• プロキシは、私が呼び出す別のアプリへのリクエスト/レスポンスを複製しますmonitor
• アプリはフローを分析し、monitorプロキシを制御して特定の IP を制限/ブロックします。
• アプリはmonitor一緒に実行され、ダウンしてもアプリケーションとプロキシには影響しません。

このアプローチは実現可能に思えます。しかし、プロキシは へのアップストリーム接続の再利用をサポートしていないようmonitorです。

プロキシからクライアントへの接続が 10,000 確立されているとします。その後、プロキシもmonitorアプリへのアップストリームとして 10,000 の接続を確立しますか? それは受け入れられません。

プロキシ間で 1 つまたは複数の接続が確立されmonitor、重複した要求/応答が送信されることを期待しています。確かに、プロキシはmonitor各要求/応答の実際のソース/ターゲットに通知します。

この要件を満たすプロキシまたは製品はありますか?