Don't overwrite existing Authorization headers (breaks Solid-OIDC/DPoP) #5

Problem

Podkey's fetch/XHR interceptors in `src/nip98-interceptor.js` and `src/injected.js` unconditionally overwrite the request's `Authorization` header, even when the page already set one (e.g., `Authorization: DPoP ` for Solid-OIDC).

Result: any page using Solid-OIDC — including the pilot app on `test.solid.social` — has its DPoP access token replaced by Podkey's NIP-98 signature. JSS then authenticates the request as `did:nostr:` instead of the user's real WebID, and ACL denies access to the user's own profile. User gets 403 on writes.

Observed in JSS issue #306.

Code pointers

• `src/nip98-interceptor.js:72,75,96,98,129`
• `src/injected.js:41,44,67,69,110,112,144`

All of these unconditionally assign `Authorization` without checking whether the page already set one.

Fix

Before injecting, check if an `Authorization` header is already present. If yes, skip Podkey's injection — the page is already authenticating itself and Podkey shouldn't interfere.

The 401-retry path is different: if the page's own Authorization failed (401), Podkey can retry with NIP-98 (this behavior stays). The fix is specifically about the initial request.

Workaround

Disable Podkey (or use incognito) when using Solid-OIDC apps. Not acceptable long-term.