GuyStore — Bug Fixes & Issue Log

Root Cause — in-memory EF store does not persist; DataSeeder never seeded images

Where did the images go? The EF Core in-memory database is destroyed every time the application process stops or restarts. Any product images uploaded through the admin UI existed only in that in-memory store — they were never written to disk or a real database. When the app switched to SQL Server, it started with a completely fresh database where no images had ever been stored.

Why DataSeeder didn't help: Data/DataSeeder.cs created all 8 products with ImageData = null and ImageMimeType = null — images were never part of the seed. The seeder only created product names, prices, and descriptions.

Why the view showed "No Image": Controllers/ShopController.cs set HasImage = p.ImageData != null. Since all products had ImageData = null, every card evaluated to false and fell back to the "No Image" placeholder.

Key inference: This is not a migration bug — the migration ran correctly. The data simply never existed in a persisted form. The solution is to seed images into the new SQL Server database rather than trying to recover them.

Homepage - ImageUrl fallback missing

Views/Home/Index.cshtml line 58 checked p.ImageData != null but never fell back to p.ImageUrl. The model passed to the homepage is IEnumerable<Product> (raw EF entities), so p.ImageUrl was available but unused.

Shop - picsum.photos images do not match product names

The picsum.photos seed-based URL format (https://picsum.photos/seed/keyboard/400/300) returns deterministic but random real-world photos - nature, architecture, people - that have no visual connection to the seeded products. A keyboard product showing a landscape photo is misleading.

InvalidOperationException: IResponseCachingFeature is not available

ShopController.Image() carries this attribute:

[ResponseCache(Duration = 3600, VaryByQueryKeys = ["id"])]

The VaryByQueryKeys property requires ResponseCachingMiddleware to be registered in the pipeline. At runtime it calls context.HttpContext.Features.Get<IResponseCachingFeature>() and throws InvalidOperationException if the feature is not present — returning a 500 for every image request.

The gotcha with VaryByQueryKeys: Most [ResponseCache] attributes work without any middleware registration (they just emit Cache-Control headers). VaryByQueryKeys is the exception — it needs the server-side response cache middleware to split cached content by query string. There is no compiler warning or startup-time error; the crash only happens at the moment the action is invoked. It is easy to add the attribute and forget the middleware.

Why was this hidden until now? Before the migrations added binary data, HasImage was always false for every product. Views used placehold.co URLs directly — the /Shop/Image/{id} endpoint was never called, so the exception was never triggered. Once ImageData was populated by Fix 2's migration, HasImage became true and every product card tried to load from /Shop/Image/{id}, hitting the 500 on every request simultaneously.

Root Cause — Newtonsoft.Json ignores System.Text.Json attributes; Fido2NetLib v4 uses STJ exclusively

The JavaScript error occurs in passkey.js inside base64urlToArrayBuffer() at the first .replace() call when options.challenge is undefined.

Background on the library: The NuGet package used is Fido2.AspNet v4.0.1 (namespace Fido2NetLib). Starting with v4, the library switched from Newtonsoft.Json to System.Text.Json throughout. All its model properties are decorated with [JsonPropertyName("camelCaseName")] (System.Text.Json attribute), which controls the JSON key name when using STJ.

Why the mismatch happens: PasskeyController.BeginAuthentication() was serialising the AssertionOptions object with JsonConvert.SerializeObject() (Newtonsoft.Json). Newtonsoft does not read [JsonPropertyName] attributes — those are STJ-only. Newtonsoft falls back to its own naming convention (C# property names → PascalCase by default). The browser therefore receives { "Challenge": "...", "AllowCredentials": [...] } instead of { "challenge": "...", "allowCredentials": [...] } (the lowercase keys the WebAuthn spec requires). options.challenge is always undefined in JavaScript, and the first .replace() call crashes.

Why it wasn't obvious: The server returned HTTP 200 with a JSON body — there was no error on the server side. The bug was silent until JavaScript tried to read the wrong-cased keys.

Root Cause — two simultaneous failures: RP ID locked to "localhost", and Origins list missing guydev.ca

Failure 1 — RP ID mismatch (browser-side check): WebAuthn's security model requires the Relying Party ID (Fido2:ServerDomain) to be either equal to or a registrable domain suffix of the origin the browser is visiting. When the app is reached via https://www.guydev.ca, the browser's effective domain is www.guydev.ca. The RP ID was localhost, which is neither equal to guydev.ca nor a suffix of it. The browser rejects the ceremony before anything reaches the server — this is the error message the user sees.

Failure 2 — Origins not whitelisted (server-side check): Even if the browser had somehow accepted the ceremony, Fido2NetLib verifies on the server that the origin claim embedded in the authenticator's clientDataJSON is in the Fido2:Origins list. Fido2:Origins only contained http://localhost:5090 and https://localhost:7091 — https://www.guydev.ca was absent, so the server would have rejected it too. Both the RP ID and the Origins list needed updating.

Why it worked in VS 2022: Visual Studio sets ASPNETCORE_ENVIRONMENT=Development automatically. The app loaded appsettings.json (ServerDomain: localhost, Origins: localhost ports) — matching the browser origin exactly. IIS deployed the same appsettings.json as the Production environment with no Development override, and the browser origin was now https://www.guydev.ca, causing both checks to fail simultaneously.

How we confirmed it was a config issue and not a code bug: The error message explicitly names the RP ID mismatch. Checking appsettings.json showed ServerDomain: "localhost" — an obvious mismatch once seen. No code logic was wrong; only the configuration values were environment-specific.

Why it failed — passkeys are bound to both domain AND device

WebAuthn passkeys are domain-bound and device-bound. Two separate bindings are enforced:

Domain binding (RP ID): A passkey registered under RP ID guydev.ca can only be used on guydev.ca. A passkey registered on localhost cannot be used on guydev.ca, and vice versa — the authenticator embeds the RP ID at registration time and the browser enforces this on every sign-in. There is no way to migrate or transfer a passkey across domains.

Device binding: A passkey registered using Windows Hello on a PC is stored in that PC's TPM or credential store and cannot be used from an iPhone (unless the passkey was explicitly synced via iCloud Keychain, Google Password Manager, or a similar cross-device sync mechanism). Scanning a QR code only works if the phone itself already has a passkey registered for that domain — the QR code is the transport, not the credential.

When the user scanned the QR code, the phone looked for an existing passkey for guydev.ca, found none (because no passkey had ever been registered on that domain or synced to that phone), and the ceremony failed. This is not a bug — authentication and registration are separate flows. You cannot sign in with something that has never been registered.

Root Cause — PasskeyController.Manage() returned the wrong view

The Profile page has <a asp-controller="Passkey" asp-action="Manage">Passkeys</a>, which navigates to GET /Passkey/Manage. The Manage() action ended with return View().

ASP.NET Core's view engine resolves a bare return View() by looking for Views/{ControllerName}/{ActionName}.cshtml — in this case Views/Passkey/Manage.cshtml. That file does not exist. There is no Views/Passkey/ folder at all; the passkey management view lives at Views/Account/Passkeys.cshtml.

In production the view-not-found exception is swallowed by the global error handler, producing the generic 500 page. The mismatch went unnoticed because the Passkeys page had never been exercised on the deployed site before.

Root Cause — Missing /.well-known/webauthn endpoint (Related Origins validation)

The app is served at https://www.guydev.ca but the WebAuthn RP ID is set to the apex domain guydev.ca. These are different — guydev.ca is a registrable domain suffix of www.guydev.ca, not an exact match.

The WebAuthn specification's Related Origins feature requires that when an RP ID is a parent domain of the actual origin, the authenticator must verify the claim by fetching https://{rpId}/.well-known/webauthn and confirming that the JSON response lists the origin as allowed. Cross-device authenticators (including Microsoft Authenticator and Google's FIDO2 stack) enforce this strictly.

Because no such endpoint existed on the server, Microsoft Authenticator fetched https://guydev.ca/.well-known/webauthn, received a 404, and rejected the ceremony with "Microsoft Authenticator doesn't support this passkey" — a misleading message that really means "RP ID ownership could not be verified".

Note: Same-device authenticators (Windows Hello, Face ID, Touch ID) often skip the /.well-known/webauthn check because they rely on the browser's same-origin policy instead. This is why the error appears only with Microsoft Authenticator (a cross-device/roaming authenticator).

Root Cause — Cloudflare apex-to-www redirect intercepts the /.well-known/webauthn lookup

The RP ID was guydev.ca (apex domain). WebAuthn Related Origins validation requires the authenticator to fetch https://guydev.ca/.well-known/webauthn — specifically from the RP ID host, not the page origin.

Cloudflare is configured to redirect all traffic from the apex domain (guydev.ca) to the www subdomain (www.guydev.ca) via an HTTP 301/302 redirect. When Microsoft Authenticator fetches https://guydev.ca/.well-known/webauthn, Cloudflare returns a redirect response instead of the JSON payload.

The WebAuthn spec and most authenticator implementations do not follow redirects on the /.well-known/webauthn lookup — a redirect is treated as failure. So the endpoint at https://www.guydev.ca/.well-known/webauthn returned correct JSON, but that URL was never actually fetched for the Related Origins check; guydev.ca was fetched and redirected, causing the rejection.

This is a subtle but critical distinction: the Related Origins lookup always goes to https://{rpId}/.well-known/webauthn, and if the RP ID host redirects rather than responds, the ceremony fails regardless of what the redirected destination returns.

Root Cause — Newtonsoft.Json cannot decode base64url byte arrays from Fido2NetLib types

This is the same Newtonsoft vs System.Text.Json serializer mismatch that caused Issue 4, but on the incoming request side.

The browser's WebAuthn API returns byte arrays (challenge, rawId, attestationObject, clientDataJSON, signature, etc.) as base64url — a URL-safe variant that uses - and _ instead of + and /, and omits = padding. passkey.js converts these ArrayBuffers and sends them as base64url strings in the JSON body.

Fido2NetLib v4 declares all its byte[] properties (e.g. RawId, AttestationObject, ClientDataJson, Signature) with [JsonConverter(typeof(Base64UrlConverter))] — a System.Text.Json custom converter that decodes base64url correctly.

PasskeyController.CompleteRegistration and CompleteAuthentication used JsonConvert.DeserializeObject<T> (Newtonsoft.Json). Newtonsoft does not read [JsonConverter] attributes from System.Text.Json and falls back to its own byte[] handling, which uses standard Base64. Standard Base64 rejects - and _ with the error above.

The ceremony appeared to reach the server (the Windows Hello biometric prompt completed successfully) but failed the moment the server tried to parse the authenticator's byte arrays from the request body.

Root Cause 0 — iCloud Keychain not enabled as a passkey provider at all (Attempt 1)

When the passkey provider list in Settings → General → AutoFill & Passwords → Password Options does not include iCloud Passwords & Keychain, iOS has no platform passkey provider to offer. Instead of showing Face ID, the provider picker sheet shows the QR code / cross-device option as the only available path. This is not a QR code flow — it is iOS telling the user "there is no platform passkey provider available; cross-device is your only option."

Fix: Settings → [Apple ID name at the top] → iCloud → Passwords & Keychain → toggle on. This registers iCloud Keychain as the device passkey provider. On the next attempt, iCloud Keychain appeared in the provider picker — but then came the next problem.

Root Cause A — No AuthenticatorAttachment specified; iOS shows provider-selection popup instead of going directly to Face ID (Attempt 2)

When AuthenticatorAttachment is not set in AuthenticatorSelection, the browser allows any type of authenticator (platform or cross-platform). On iOS this triggers a provider-selection sheet asking which passkey manager to use. If multiple providers or unknown state, iOS shows the "Choose how to manage your passkeys" popup rather than going straight to Face ID.

The frozen popup on Attempt 2 was caused by iOS attempting to deep-link to Settings while the navigator.credentials.create() promise was still pending in Safari — the page appeared frozen because the WebAuthn ceremony timeout hadn't fired yet. Rebooting the iPhone cleared the stuck promise.

Root Cause B — iCloud in a silent broken authentication state (Attempt 3 and beyond)

After rebooting, the popup was no longer frozen but showed only "Open 'AutoFill & Passwords'" with no provider options — meaning iOS had no passkey provider available at all, even though iCloud Keychain had just been enabled. This persisted even though:

• Face ID was set up and enrolled correctly (confirmed in Settings → Face ID & Passcode)
• iCloud Keychain sync toggle was enabled (Settings → [Apple ID] → iCloud → Passwords & Keychain)
• Settings → General → AutoFill & Passwords → Password Options showed iCloud Passwords & Keychain as the active provider
• No error banner or warning appeared anywhere in Settings → Apple ID

Key diagnostic step — webauthn.io isolation test: The same popup appeared on https://webauthn.io, an independent public WebAuthn test site with no connection to GuyStore. This confirmed the failure was device-wide — not a GuyStore code bug, RP ID mismatch, or configuration error. Any app on the device would have seen the same result.

Why Face ID being set up does not fix this: Face ID and the passkey provider are separate systems. Face ID is a biometric sensor. The passkey provider is iCloud Keychain, which is a cloud-backed credential store. Even when Face ID works perfectly, if the passkey provider (iCloud Keychain) is broken, iOS cannot complete the passkey ceremony — it cannot offer the Face ID prompt because there is no provider to store the credential into.

Root cause: iCloud was in a silent expired/broken authentication state. The Passwords provider appeared registered in settings, but internally its session token was stale or corrupted. It could not actually serve as a passkey provider. No visible error surfaced in Settings.