Skip to content

Credentials & Permissions

Symptom

Test connection fails with AccessDenied or an HTTP 403 response.

Likely causes

  • The IAM policy (or equivalent access-key permission) is missing required actions (GetObject, PutObject, DeleteObject, ListBucket, etc.)
  • The policy is attached to the wrong user/key
  • The policy is scoped to the wrong bucket, or to a key prefix that doesn’t match what’s configured in Universal Storage → Storage

Steps to diagnose

  1. Confirm which user/key is actually being used — under AWS, check IAM → Users → your plugin’s user → Permissions.
  2. Compare the attached policy against the one generated for you on Universal Storage → Health (pre-filled for your current bucket/prefix).
  3. Run wp universal-storage test for a CLI-side check independent of the admin button — useful if the admin UI’s test button itself is timing out rather than failing cleanly.

How credentials are stored

Secret access keys are encrypted at rest (libsodium sodium_crypto_secretbox, with an AES-256-GCM fallback), keyed off your WordPress salts. They’re never stored in plaintext, never written to logs, and never returned by the REST API or admin HTML once saved — the secret field stays blank on later edits, and leaving it blank on save keeps the existing value rather than clearing it.