[Andrew Gaul (gaul)]

A service SAS for a single blob version has signed resource bv and signs the version ID in the string-to-sign field where a snapshot SAS signs the snapshot time. The SDKs generate one whenever a SAS is requested for a client bound to a version, for example blobClient.withVersion(id).generateSasUrl(...). Azurite refused the resource type outright, so such a SAS URL could not read the version it named. Copy Blob and Put Blob From URL fetch their source over that same SAS path, so a copy from a version SAS URL failed with CannotVerifyCopySource. #2735 lists this among its limitations.

This change accepts bv and reads the signed value from the request's versionid query parameter. It signs the blob name in the canonicalized resource. Because the version ID is in the signature, the SAS authorizes the version it names and nothing else: another version, or the current blob, gets 403.

A version SAS is checked against a permission table of its own. The table lists only the operations whose handlers act on the version that versionid names: Get Blob, Get Blob Properties, Get/Set Blob Tags, Set Blob Tier and Delete Blob. Any other operation would act on the base blob, so it gets AuthorizationResourceTypeMismatch. Deleting the version takes the Delete version permission (x), as Azure requires, rather than d.

A snapshot SAS (bs) gets the same treatment. It used to be checked against the container table, so a writable one could set the base blob's metadata. Its table lists Get Blob, Get Blob Properties, Get Block List, Get Page Ranges, Delete Blob and Get/Set Blob Tags. Set Blob Tier is left out because its handler ignores the snapshot selector. A bs or bv SAS with a signed version before 2018-11-09 is refused, because those signing formats bind neither the resource nor the snapshot or version.

Get Block List on a snapshot listed the base blob's uncommitted blocks for all or uncommitted, under any authorization, because both stores looked staged blocks up by blob name alone. A snapshot has no uncommitted blocks, so they are now listed only for the base blob.

The user delegation string-to-sign builders left the snapshot-time field empty for every resource, and two of them signed the blob name only for b. So a user delegation SAS was refused for a version and for a snapshot alike. They now sign both, as the shared-key builders already did for snapshots.

Tests in blockblob.versioning.test.ts:

• a version SAS reads its version;
• it does not read another version or the current blob;
• it cannot write the base blob or read its block list;
• it deletes its version with x, but not with d alone;
• a snapshot SAS, whether signed with the account key or a user delegation key, cannot set the base blob's metadata;
• a snapshot or version SAS signed in the 2017-11-09 format is refused, while the same token for the blob itself is accepted;
• a snapshot SAS reads the snapshot's block list and page ranges, and Get Block List on a snapshot lists no uncommitted blocks (blockblob.test.ts, @loki @sql);
• Put Blob From URL and Copy Blob copy from a version SAS URL;
• a user delegation SAS reads a version and a snapshot.

Every new test except the one about other versions fails without the change. That one also passed before, when every version SAS was refused. The full @loki blob suite passes, and lint and tsc are clean. I could not run the @sql suite locally, so the SQL store change is covered only by CI.

I found this while testing S3Proxy's Azure versioning support (gaul/s3proxy#1139), which copies a version by its SAS URL, against Azurite main.

References #665.

[Copilot]

🟡 Changes recommended

Critical SAS authorization flaws allow version-scoped tokens to access or modify the current blob and permit version deletion with d while rejecting the required x permission.

2 open issues

• Reject version SAS on handlers that ignore its version selector · New
• Require DeleteVersion permission for version SAS deletions · New

What changed in this PR

This PR adds version-scoped SAS support to Azurite’s Blob authentication, addressing a limitation of the existing Loki-backed versioning implementation.

Changes:

• Accepts bv resources and includes the version ID in signature validation.
• Corrects snapshot and version signing for user delegation SAS.
• Adds read, isolation, and copy tests and updates support documentation.

1. Impact analysis

   • Package: Azurite Blob service; no package version change shown.
   • Usage: Reading and copying blob versions through SAS URLs.
   • Impact and risk: Authorization boundaries remain sensitive.

2. Build and conflict resolution

   • Commands run: None; verification was limited to source inspection.
   • Result: Build and merge-conflict status were not independently verified.

3. Tests

   • Added: Version reads, selector tampering, copy operations, and user delegation reads.
   • Coverage: Additional authorization regression tests are needed.

4. Test suite

   • Commands run: None.
   • Passing: The PR description reports a passing Loki Blob suite, lint, and TypeScript checks.
   • Pending: Independent execution and follow-up regression coverage.

5. Changelog

   • Entry added: Version SAS support and corrected snapshot user delegation signing.
   • Location: ChangeLog.md, Blob section.

6. PR comments

   • Threads reviewed: Authentication and authorization feedback.
   • Actions taken: Clarified required changes and fix guidance.
   • Unresolved items: Two actionable comments remain.

7. Self-rating

   • Score: Not assigned.
   • Reasoning: Source evidence supports the comments; runtime validation was not performed.

8. Iteration

   • Improvements made after self-review: Tightened explanations and checked proposed fixes against existing permission handling.

9. Summary

   • Why the update matters: Enables SDK-generated SAS URLs for individual versions.
   • Risk if not applied: Version-SAS reads and copies remain unsupported.
   • Final status: Follow-up authorization changes and tests are needed.

File	Description
tests/​blob/​apis/​blockblob.versioning.test.ts	Adds version-SAS read, isolation, copy, and delegation tests.
src/​blob/​authentication/​IBlobSASSignatureValues.ts	Updates canonical resource and snapshot/version signing.
src/​blob/​authentication/​BlobSASResourceType.ts	Defines the bv resource type.
src/​blob/​authentication/​BlobSASAuthenticator.ts	Accepts bv, reads versionid, and selects blob permissions.
README.md	Removes version-SAS support limitations.
docs/​designs/​2025-12-blob-versioning.md	Documents version-SAS signing and updates limitations.
ChangeLog.md	Records version and snapshot SAS support changes.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Critical SAS isolation flaws allow legacy version tokens to access other blob versions and writable user delegation snapshot tokens to modify the current blob, requiring authorization fixes and regression tests.

2 open issues

• Reject legacy SAS formats that do not bind blob versions · New
• Prevent snapshot SAS writes from modifying the base blob · New

2 resolved since last review

• Require DeleteVersion permission for version SAS deletions
• Reject version SAS on handlers that ignore its version selector

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

The snapshot SAS allowlist rejects valid Get Page Ranges and committed block-list reads; restoring access also requires guarding against exposure of the base blob’s uncommitted blocks and adding regression tests.

1 open issue

• Restore snapshot Read authorization without exposing base-blob blocks · New

2 resolved since last review

• Prevent snapshot SAS writes from modifying the base blob
• Reject legacy SAS formats that do not bind blob versions

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

No active review issues are recorded for the version-scoped SAS and snapshot authorization changes.

No open issues 🎉

1 resolved since last review

• Restore snapshot Read authorization without exposing base-blob blocks

_{Review effort: Balanced}