hosting

GET /v1/sites/{siteId}/protection/file-permissions

Run the vendor's file-permission check on a site.

すべての hosting エンドポイント

すべての開発者向けドキュメント

認証

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

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

試してみる

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

curl -X GET https://api.zinndigital.com/v1/sites/{siteId}/protection/file-permissions \
  -H "Authorization: Bearer zdk_live_…"

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

詳細

This GET RUNS the scan — it is not a cached read. The vendor's read is the check, so it walks the site's filesystem. It is an explicit "check my permissions" action and must never fire on mount or on window focus. check_id is the handle the fix needs, and it is nullable: null means the vendor gave us no handle, so actionable is false and there is nothing to apply. recommended on each failure is nullable for the same reason — the platform sometimes names a file without naming a mode, and a guessed 644 would be applied to the customer's file. 404 for a site with no vendor hosting package. Requires sites.view.

パラメータ

名前タイプ必須これがその内容です
siteId (path)UuidはいSite ID (UUIDv7).

返信

名前タイプ必須これがその内容です
check_idintegerはいThe vendor's handle for this check. Null when the vendor gave us none, in which case there is nothing to apply and actionable is false. ⛔ A client never sends it back:…
public_html_wrongbooleanはいWhether the document root's own mode is wrong.
root_wrongbooleanはいWhether the package root's own mode is wrong.
failuresSitePermissionFailure[]はいThe individual files the check flagged.
actionablebooleanはいWhether Fix these can do anything: a live check handle and something to fix. Its own field so the button is not offered against a report that can only be refused.

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

401 · 403 · 404 · 429 · 503