Proxy-seller

承認

Updated:

注文ごとに、プロキシアクセス用の固有の認証情報を生成・管理します。

仕組み

  1. 注文する

    POST /order/make

  2. generateAuth=Y

    発行された一意の認証情報

  3. /auth 経由で管理する

    一覧 · 更新 · 取り消し

注文作成時に認証情報を生成する

送信generateAuth=Y ~へ/order/make 返されたものに紐付けられた一意の認証情報を発行するorderNumber.

POST/ja-JP/order/make?generateAuth=Y

これらの認証情報を保存してください。以下のコマンドで生成された認証情報は、generateAuth=Y 以下には記載されていません/proxy/list. 返された値を通じてそれらを取得しますorderNumber.

権限の管理

プロキシ注文に関連付けられた認証情報に対する4つの操作。

GET/auth
権限の一覧
どのログインIDとパスワードの組み合わせ、またはホワイトリストに登録されたIPアドレスがアクセス権限を持っているか。
Use when: auditing all data tied to a client email.
POST/auth
承認を作成する
注文ごとに、カスタム認証情報を発行するか、ランダムな認証情報を発行する。
Use when: onboarding a team member or sub-user.
PATCH/auth/{id}
承認の変更
ユーザーの既存のアクセス権を変更します。
Use when: leak suspected or scope needs tightening.
DELETE/auth/{id}
承認の削除
不要になった権限を削除してください。
Use when: access period expires.

関連情報

GET/ja-JP/proxy/list - find the orderNumber
POST/ja-JP/order/make - place a new proxy order

よくある質問

典型的な構成:1組のログインIDとパスワード、および認証用のIPアドレスが限定されている。

login:password: 動的IPアドレスを持つスクリプトおよびモバイルクライアント。IPホワイトリスト: 安定した固定IPアドレスを持つサーバー。これらは同じ注文内で共存可能です。これらは別々の認証レコードです。

すぐに接続が途切れ始めます。電話してくださいchange-authorization 新しいip レコードを再作成せずに更新するためです。通信中の接続は数秒以内に切断されます。

その認証情報セットに限った現象です。同じ注文に含まれる他の認証レコードは引き続き正常に機能します。

はい。/auth/list リターンlogin そしてpassword そのアカウントにおけるすべての認証について、平文で、さらにid,active そしてorderNumber. IPホワイトリストのレコードについては、ip も返されます。個別の「reveal」エンドポイントは存在せず、リスト表示が復旧手段となります。

復元するよりも回転させたい場合は、次のコマンドを使用してください。change-authorization 新しいパスワードを設定するには。

いいえ。デフォルトでは、新規注文は共有アカウントレベルの認証情報を使用して認証されます。一意のlogin:password 特定の順序に縛られる、パスgenerateAuth=Y ~へ/order/make (または/prolong/make (更新時)。このフラグを指定しない場合、すべての注文で同じデフォルトのペアが再利用されます。

一意の認証情報が、返されたorderNumber そして、後で以下の方法で取得できます/auth/list. もしスキップした場合はgenerateAuth=Y 既存の注文に別のペアを追加したい場合は、以下を使用してください。/auth/add 明示的に。

単一のIPv4およびIPv6アドレスがサポートされています。CIDR表記はではない 対応済み — 必要なアドレスを列挙してください。

開いているTCPセッションは数秒以内に切断されます。段階的な切断は行われません。認証情報の削除は、即座に接続を切断するキルスイッチとして扱ってください。

On this page

承認 | Proxy-seller