OSS Browser Direct Upload & CORS Diagnosis

Diagnose Alibaba Cloud OSS browser / mini-program / frontend direct-upload failures: "my web page upload reports a CORS error", "I configured CORS but it is not working", "the browser says No 'Access-Control-Allow-Origin'", "mini program upload failed with 403", "please set the ETag of expose-headers", "PostObject reports the policy is expired".

Core approach: verify the caller identity, confirm the bucket exists via the read-only GetBucketInfo control-plane query, read the bucket's real CORS rules with the read-only GetBucketCors query, match the browser Origin against the rules (preflight attribution), audit expose-headers for the headers browser SDKs need (ETag / x-oss-request-id), and check PostObject form-upload policy semantics (UTC expiration, form fields, x: custom variables). Conclude with evidence-based findings plus standard configuration templates. This skill only outputs templates — it never writes any configuration (applying CORS via PutBucketCors or the console is the user's own manual operation).

Absolute Rules

1. ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating OSS API — e.g. PutBucketCors, DeleteBucketCors, PutBucket*, DeleteBucket*, PutObject*, DeleteObject*, or any ACL/policy/configuration change. This includes commands "for the user to run manually". When a CORS change is needed, only output the standard template as text and manual guidance, and declare this skill is read-only.
2. MANDATORY entry-point enforcement: All diagnostics MUST be performed by running the scripts under scripts/ (oss_cors_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own ossutil / SDK / curl commands against the OSS control plane or bypassing the scripts — the scripts embed timeout, error degradation, and observability guarantees that ad-hoc commands lack. Read the script output, interpret it, and compose the report; do not re-implement the queries.
3. ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass AK/SK/STS tokens explicitly. The OSS SDK resolves credentials exclusively from the environment variables of the default credential chain; the identity check uses the aliyun CLI default credential chain. Never accept AK/SK from the user or from another script. This prohibition covers the command line itself: never prefix a command with inline credential assignments such as ALIBABA_CLOUD_ACCESS_KEY_ID=... ALIBABA_CLOUD_ACCESS_KEY_SECRET=... python3 ..., and never pass credentials as CLI arguments, in heredocs, or in any echoed/executed command text — an inline assignment lands verbatim in the execution log and counts as a credential leak. The diagnosis environment already has the credential chain in place: run python3 scripts/oss_cors_diagnosis.py ... exactly as written (bare command, no credential prefix) and the scripts resolve credentials on their own. If a run fails with "no credentials found", report the failure and guide the user to run aliyun configure — never fetch, read, or inline credentials yourself.
4. NO FABRICATION: Every conclusion must be grounded in data actually returned by GetBucketInfo / GetBucketCors / ListBuckets / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation — never invent CORS rules, bucket locations, or request headers.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> to stderr, continue with the remaining steps (including the ListBuckets fallback), and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line — never silently skip or abort without a report. Note: a bucket with no CORS rule returns NoSuchCORSConfiguration from GetBucketCors — this is the semantic state "CORS not configured", NOT an error; report it as a finding and output the standard template.
6. SCOPE BOUNDARY: This skill only answers browser/mini-program direct-upload attribution and CORS/PostObject configuration-check questions. It does NOT handle server-side SDK upload/download error codes, multipart upload mechanics, endpoint/region selection, signed URLs, billing, or attack forensics — for such requests, state the boundary and defer to the sibling skill listed in the frontmatter.

Official Doc Verification

MANDATORY: For configuration or usage questions, the entry script MUST be invoked with --question "". The script first matches embedded knowledge, then verifies against official OSS docs (doc_verification, llms-index). The final answer MUST cite the URLs from doc_verification.docs. If doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)." Never fabricate doc URLs; only URLs returned by the script may be cited.