pro/im_webapp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: don't route already-absolute avatar URLs through authenticated fetch

Browse Source 
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.
This commit is contained in:
Your Name
2026-09-18 15:13:27 +08:00
parent 7fff1a7b3a
commit 74f4e753ef
1 changed files with 15 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
web/src/app/Avatar.tsx
+15 -9
View File
@@ -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}`}>