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
- Confirm which user/key is actually being used — under AWS, check IAM → Users → your plugin’s user → Permissions.
- Compare the attached policy against the one generated for you on Universal Storage → Health (pre-filled for your current bucket/prefix).
- Run
wp universal-storage testfor 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.