OSS Presigned URL Diagnosis & V4 Upgrade Guidance

Diagnose Alibaba Cloud OSS presigned (signed/share) URL failures and guide the V1-to-V4 signature migration: "our share link expired", "SignatureDoesNotMatch on presigned URL", "V1 signature is forbidden after upgrading the SDK", "x-oss-credential error in the URL", "the signed URL stops working after one day". Chinese ticket wording lands here too (eval fix PR-2): overnight-dead share links, signature-mismatch or tampered-link reports, persistent V4 signing failures, custom-domain signed-URL errors, make-the-link-permanent requests, proxy header-rewrite and SDK-config causes — the embedded catalog carries the Chinese keyword layer.

Core approach: parse the pasted presigned URL locally as a pure string (never send it anywhere; access keys and signatures are masked), detect the signature version (V1 OSSAccessKeyId+Expires+Signature vs V4 x-oss-credential+x-oss-date+x-oss-expires+x-oss-signature), extract and evaluate the expiry (V1 absolute epoch; V4 x-oss-date + x-oss-expires, max 604800 seconds = 7 days for a long-term AccessKey; STS temporary credentials cap at 43200 seconds = 12 hours), then route the reported error code / HTTP status / symptom / original question wording through the embedded failure-mode catalog to root-cause directions (expired, clock skew beyond +/-15 minutes, V1 signature forbidden, URL parameter tampering incl. proxy header rewriting, credential rotation or STS expiry, permission change after signing incl. AK network-policy / IP-allowlist restrictions, HTTP method mismatch, malformed signature parameters, SDK configuration misuse such as pathStyleAccess), and deliver the V4 upgrade compatibility checklist plus share-link recovery steps. This skill makes zero cloud API calls and performs no live network probing; all reasoning comes from the catalog distilled from official documentation and the presigned-URL support-ticket cluster (~130 tickets/month).

Absolute Rules

1. MANDATORY entry script: All diagnosis MUST be performed by running python3 scripts/oss_presigned_url_diagnosis.py with the parameters gathered from the user. The Agent is forbidden from diagnosing by free-form reasoning alone or bypassing the script — the script embeds the URL parser, the expiry arithmetic, the failure-mode catalog, and the V4 upgrade checklist.
2. ABSOLUTE PROHIBITION (no writes, no cloud calls, no probing): Under NO circumstances may you invoke any mutating OSS operation, any aliyun CLI command, or any cloud API from this skill, and you MUST NOT fetch, curl, or otherwise probe the presigned URL over the network. The URL is analyzed purely as a string by the script. Do not read, print, or accept AK/SK/STS tokens; no credentials are needed at all. When the user pastes a URL, pass it to --url only; the script masks keys and signatures in its output.
3. NO FABRICATION: Every signature-version rule, expiry limit, failure mode, root-cause direction, and troubleshooting step MUST come from the script output (which reflects the embedded catalog sourced from official documentation). Never invent error codes, limits, or doc links. If the input matches no catalog entry, say so and ask for the presigned URL or the full error response body.
4. EXECUTION RULE FOR ERRORS: If the script exits with STATUS: FAIL, report the failure reason verbatim from NEXT_ACTION and ask the user for the missing input (the presigned URL itself and/or the full error body: Code, Message, RequestId). Never silently guess a diagnosis. On STATUS: DEGRADED, present the candidate failure modes in order and ask for the discriminating evidence before concluding.
5. SCOPE BOUNDARY: This skill only diagnoses presigned-URL failures and V1→V4 migration readiness. It does NOT teach signature-algorithm implementation, generate signed URLs, handle DDoS sandbox mitigation, deleted-data recovery, or commercial refunds — for such requests, state the boundary, point to the sibling skill listed in the description where applicable, and recommend a human support ticket.

Official Doc Verification