From 74f4e753eff8e82193902e822d8be6fda45b533d Mon Sep 17 00:00:00 2001
From: Your Name <aa@bb.com>
Date: Fri, 18 Sep 2026 15:13:27 +0800
Subject: [PATCH] fix: don't route already-absolute avatar URLs through
 authenticated fetch

Default-avatar placeholders return avatar_file_id as a complete OSS URL
rather than a short file id. The previous fix stopped re-wrapping that
URL into a malformed /v0/file/s/https://... request, but still routed
it through useAuthedBlobUrl's authenticated fetch -- live-confirmed
that OSS bucket serves default avatars with no CORS headers at all, so
the cross-origin fetch carrying auth headers gets blocked at preflight
and the tile silently falls back to the plain letter. An absolute URL
needs no credentials; render it directly as a plain <img src> instead.
---
 web/src/app/Avatar.tsx | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/web/src/app/Avatar.tsx b/web/src/app/Avatar.tsx
index 06294838..b58fb8e3 100644
--- a/web/src/app/Avatar.tsx
+++ b/web/src/app/Avatar.tsx
@@ -22,18 +22,24 @@ interface AvatarProps {
  * avatar produced zero visible change anywhere, including on the very page the upload happened.
  * `avatar_file_id` is USUALLY a bare file id (e.g. "abc123"), needing the `/v0/file/s/{id}` shape
  * `useAuthedBlobUrl` (same authenticated-fetch-to-blob-URL mechanism already used for chat
- * attachments) reconstructed -- but live-confirmed (2026-09-18, real console error): default-avatar
- * placeholders come back as an ALREADY-COMPLETE OSS URL in this same field (e.g.
- * "https://im-oss-t1.oss-cn-shenzhen.aliyuncs.com/im-assets/default-avatars/male/2.png"), which this
- * used to unconditionally re-wrap into "/v0/file/s/https://...", a malformed request that 404s.
- * `useAuthedBlobUrl`/`fileDownloadUrl` already accept either shape (see hooks.ts's own comment) --
- * only needed to stop force-prefixing a value that's already a full URL.
+ * attachments) reconstructed -- but live-confirmed (2026-09-18): default-avatar placeholders come
+ * back as an ALREADY-COMPLETE OSS URL in this same field (e.g.
+ * "https://im-oss-t1.oss-cn-shenzhen.aliyuncs.com/im-assets/default-avatars/male/4.png"). A first
+ * fix attempt stopped re-wrapping that URL into the malformed "/v0/file/s/https://..." shape but
+ * still routed it through `useAuthedBlobUrl`'s authenticated fetch -- live-confirmed that still
+ * fails: this OSS bucket's default-avatar path serves plain public assets with no CORS headers at
+ * all, so a cross-origin fetch carrying the app's auth headers (Bearer token, API key -- meaningless
+ * to OSS anyway) gets blocked at the preflight, `useAuthedBlobUrl` reports an error, and the tile
+ * falls back to the plain letter. An absolute URL never needs the authenticated-fetch-to-blob dance
+ * (that mechanism exists only to attach credentials `/v0/file/s/{id}` requires) -- render it directly
+ * as a plain `<img src>` instead, same as any other publicly-loadable image.
  */
 export function Avatar({ id, name, avatarFileId, className = '', fallbackBgClass }: AvatarProps) {
   const isAbsoluteUrl = !!avatarFileId && /^https?:\/\//.test(avatarFileId);
-  const remote = useAuthedBlobUrl(avatarFileId ? (isAbsoluteUrl ? avatarFileId : `/v0/file/s/${avatarFileId}`) : undefined);
-  if (remote.url) {
-    return <img src={remote.url} alt="" className={`object-cover ${className}`} />;
+  const remote = useAuthedBlobUrl(avatarFileId && !isAbsoluteUrl ? `/v0/file/s/${avatarFileId}` : undefined);
+  const resolvedUrl = isAbsoluteUrl ? avatarFileId : remote.url;
+  if (resolvedUrl) {
+    return <img src={resolvedUrl} alt="" className={`object-cover ${className}`} />;
   }
   return (
     <span className={`grid place-items-center font-medium text-white ${fallbackBgClass || avatarBgClass(id)} ${className}`}>