SharePoint/OneDrive anonymous sharing links (:v:/g/, :x:/g/, etc.) fail with 403/login redirect — cookie set during redirect chain is not carried forward

[rdenarie]

Summary

Anonymous SharePoint/OneDrive sharing links (format https://<tenant>.sharepoint.com/:v:/g/<id>?e=<token>) fail to resolve when fetched by Iframely, even though the same link works fine and anonymously in a real browser. The link ends up redirected all the way to login.microsoftonline.com, as if no anonymous access were granted — even though the sharing setting is genuinely "Anyone with the link".

Root cause (confirmed via curl repro)

The very first response from SharePoint on the sharing link sets a cookie establishing a temporary anonymous identity for the tenant:

HTTP/1.1 302 Found
Location: https://<tenant>.sharepoint.com/_layouts/15/stream.aspx?id=...
Set-Cookie: FedAuth=...membership|urn:spo:tenantanon#<tenantId>...; SameSite=None; secure; HttpOnly

This FedAuth cookie (anonymous tenantanon identity, derived from the e= token in the sharing link) must be sent back on every subsequent request in the redirect chain (stream.aspx / doc2.aspx / etc.). If it isn't, SharePoint has no way to resolve who the anonymous caller is supposed to be, and falls back to a full interactive OAuth login flow:

:v:/g/...?e=...  (302, sets FedAuth=...tenantanon...)
→ stream.aspx     (302 if cookie missing)
→ Authenticate.aspx (302)
→ _forms/default.aspx (302)
→ login.microsoftonline.com/.../oauth2/authorize (200 — real login page)

I reproduced this exactly with plain curl -L (no cookie jar) — it fails and lands on the Microsoft login page. Re-running the identical request with a cookie jar enabled (curl -L -c jar.txt -b jar.txt ...) succeeds with 200 OK on the final resource, without ever touching login.microsoftonline.com. A real browser behaves the same way (persists cookies across redirects automatically), which is why the link "works" when opened manually but fails when fetched by a tool that treats each redirect hop as a stateless request.

Steps to reproduce

1. Generate an anonymous "Anyone with the link" sharing link for any file (video or document) on a SharePoint Online tenant, e.g.:
   https://contoso.sharepoint.com/:v:/g/<id>?e=<token>
2. Submit it to Iframely (hosted or self-hosted) → embed fails / returns 403 (or similar).
3. Reproduce manually with curl:

   # Fails — no cookie jar, redirected to login.microsoftonline.com
   curl -L 'https://contoso.sharepoint.com/:v:/g/<id>?e=<token>'
   
   # Succeeds — cookie jar preserves the anonymous session across redirects
   curl -L -c /tmp/jar.txt -b /tmp/jar.txt 'https://contoso.sharepoint.com/:v:/g/<id>?e=<token>'

Expected behavior

Iframely should be able to fetch anonymous SharePoint/OneDrive sharing links the same way a browser does — i.e., cookies set on intermediate redirect responses within the same fetch chain should be carried forward to subsequent requests in that chain.

Possible fix / workaround

This looks related to the cookie-jar mechanism already used for the YouTube consent-cookie case (#326, #543), where a custom plugin can set options.jar before the request. The difference here is that the cookie needed isn't known in advance — it's issued by the server during the redirect chain — so the fix would need to ensure the underlying HTTP client keeps a persistent cookie jar active across the whole redirect chain for *.sharepoint.com / *-my.sharepoint.com domains (or generally, whenever Set-Cookie + Location are both present in a 3xx response).

Happy to provide more detail / test a fix if useful.