PUT /v1/compute/servers/{serverId}/firewall

認証

ベアラー トークンとして API キーを送信します。キーには sites.restart 権限が付与されている必要があります。権限のないキーは 404 ではなく 403 で拒否されます。

このエンドポイントは組織IDを受け付けません。お使いのキーによって所属する組織がすでに特定されており、レスポンスはその組織にスコープされます。

試してみる

アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。

curl -X PUT https://api.zinndigital.com/v1/compute/servers/{serverId}/firewall \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "rules": <ComputeFirewallRule[]> }'

ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く

詳細

⭐ PUT, and the verb is the contract: this replaces the entire rule set. The provider's write is atomic, and an add/remove surface layered over an atomic replace is how two people editing at once discard each other's rule with both requests reporting success. ⛔⛔ This can lock the customer out of their own machine. A set with no inbound SSH is applied exactly as asked and their next connection is refused. That is why openComputeServerConsole exists, and why a client should say so beside this control. Refused when more than one firewall is applied to the machine: the effective policy is their union, so editing one and reporting the result would be false in the dangerous direction. The whole rule set is audit-logged, not a count — when a customer reports being locked out, "12 rules were set" answers nothing. Requires sites.restart.

パラメータ

リクエスト本文

返信

このエンドポイントが返すエラー

401 · 403 · 404 · 422 · 429 · 503