POST /v1/sites/{siteId}/protection/directories

認証

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

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

試してみる

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

curl -X POST https://api.zinndigital.com/v1/sites/{siteId}/protection/directories \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "directory": <string>, "username": <string> }'

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

詳細

Puts an HTTP password on one folder under the document root. `POST` and not a `PUT` of the whole set even though the vendor endpoint replaces it: the set is rebuilt by the engine from the entries the platform itself returned, precisely because we do not hold the other folders' passwords and must not ask a customer to re-enter them to protect a new one. ⛔ **The response carries a password, and it is the only one on this surface that does.** Omit `password` and the engine generates a strong one; either way the value is returned **exactly once**, written to no record of ours, and readable back by no endpoint. The whole response is therefore a credential: a client displays it once and does not cache it, store it in a query cache, put it in a URL, or include it in an error report. `username` may not contain a colon or a space — `:` separates the name from the hash in an `.htpasswd` file, so a name containing one produces a file that parses into something other than what was written. `404` for a site with no vendor hosting package. Requires `sites.view` and `sites.panel_access`.

パラメータ

リクエスト本文

返信

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

401 · 403 · 404 · 409 · 422 · 429 · 503