feat: enhance Authorization header handling with Header Override support

[Li-Xingyu]

问题描述

在之前的实现中，Header Override 功能存在优先级问题：系统会在 SetupRequestHeader 中设置默认的 Authorization: Bearer {api_key} header，然后才应用 Header Override，导致用户自定义的 Authorization header 被覆盖。

这导致无法使用非标准认证格式的 API（如 Key xxx:yyy 格式），因为 Header Override 中的设置会被默认的 Bearer token 覆盖。

修复内容

1. 调整 Header Override 应用顺序（relay/channel/api_request.go）

   • 修改 DoApiRequest、DoFormRequest、DoWssRequest 三个函数
   • 将 Header Override 的应用移到 SetupRequestHeader 之后
   • 确保用户配置的优先级最高

2. 优化自定义渠道处理（relay/channel/openai/adaptor.go）

   • 自定义渠道类型（ChannelTypeCustom）完全跳过默认 Authorization 设置
   • 其他渠道类型检查 Header Override 是否已设置 Authorization，避免不必要的默认设置

3. 向后兼容

   • 所有修改保持向后兼容
   • 不影响现有渠道的正常使用
   • 仅提升 Header Override 的优先级

Summary by CodeRabbit

• Bug Fixes
  • Ensured user-provided headers reliably take precedence over system defaults so custom headers are applied as expected.
  • Prevented system processes from overwriting a custom Authorization header, preserving explicitly supplied credentials and avoiding unintended replacements.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Reorder header setup so SetupRequestHeader runs before applying header overrides in API, form, and WSS request paths; remove duplicate SetupRequestHeader calls. Add guards in OpenAI adaptor to avoid overwriting Authorization when an Authorization override is present.

Changes

Cohort / File(s)	Summary
Header setup reordering relay/channel/api_request.go	Call SetupRequestHeader earlier in DoApiRequest, DoFormRequest, and DoWssRequest; remove the redundant second call; keep processHeaderOverride(info) and apply overrides after initial setup (Chinese comments added noting precedence).
Authorization header guards relay/channel/openai/adaptor.go	In SetupRequestHeader, skip setting or overwriting the Authorization header when HeadersOverride already contains Authorization (applies to realtime and non-realtime branches); OpenAI-Organization behavior unchanged.

Sequence Diagram(s)

(No sequence diagrams generated — changes are focused header ordering and guards, not new multi-component control flow.)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feats:add custom headers override #1644 — similar reorder of SetupRequestHeader and header-override application in relay/channel/api_request.go.
• feats:replace GLM-4v authentication headers to support customize api key #1536 — related changes to SetupRequestHeader handling for Authorization in OpenAI adaptor.

Poem

🐰
Headers hop in tidy lanes,
Setup first, then your names;
Authorization yields its crown,
Overrides wear the highest gown,
I nibble bugs, then settle down. 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: enhancing Authorization header handling to give Header Override support higher priority, which is the core objective of the PR.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[seefs001]

@coderabbitai 原有的自定义渠道有在使用这个api key吗？该更改是否会如PR描述的兼容和不影响现有使用

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the adaptor.go file to see the SetupRequestHeader implementation
cat relay/channel/openai/adaptor.go | head -200

Length of output: 7424

---

🏁 Script executed:

#!/bin/bash
# Read the api_request.go file to see the request handling
cat relay/channel/api_request.go | head -150

Length of output: 4613

---

🏁 Script executed:

#!/bin/bash
# Search for custom channel usage patterns and ChannelTypeCustom references
rg -n "ChannelTypeCustom" -C 3

Length of output: 2780

---

🏁 Script executed:

#!/bin/bash
# Search for HeadersOverride usage to understand how it's currently used
rg -n "HeadersOverride|HeaderOverride" -C 2

Length of output: 8781

---

🏁 Script executed:

#!/bin/bash
# Look for any tests related to custom channels
fd -e go test | xargs rg -l "custom.*channel|ChannelTypeCustom" 2>/dev/null || echo "No test files found"

Length of output: 19

---

🏁 Script executed:

#!/bin/bash
# Read more of the adaptor.go to see the complete SetupRequestHeader logic
cat relay/channel/openai/adaptor.go | grep -A 30 "func (a \*Adaptor) SetupRequestHeader"

Length of output: 1117

---

🏁 Script executed:

#!/bin/bash
# Search for documentation or examples of custom channel configuration
rg -n "自定义渠道|custom channel|ChannelTypeCustom" -i -C 3 | head -100

Length of output: 4779

---

🏁 Script executed:

#!/bin/bash
# Check if there are any migration scripts or changelogs mentioning custom channels
fd -e md -e txt | xargs rg -l "custom.*channel|Header.*Override" -i 2>/dev/null | head -10

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Look for how HeaderOverride is typically used in the frontend/docs
cat web/src/components/table/channels/modals/EditTagModal.jsx | grep -B 5 -A 10 "header_override"

Length of output: 3995

---

🏁 Script executed:

#!/bin/bash
# Check git history to see the previous implementation of SetupRequestHeader
# to understand what the old behavior was for custom channels
git log --oneline --all -20 | head -20

Length of output: 1437

---

🏁 Script executed:

#!/bin/bash
# Look at the PR diff to see what was changed
git diff HEAD~1 HEAD -- relay/channel/openai/adaptor.go 2>/dev/null || echo "Cannot access git diff"

Length of output: 1804

---

🏁 Script executed:

#!/bin/bash
# Check the rest of SetupRequestHeader to see the complete old logic
cat relay/channel/openai/adaptor.go | grep -A 50 "func (a \*Adaptor) SetupRequestHeader" | tail -30

Length of output: 995

---

🏁 Script executed:

#!/bin/bash
# Search for any documentation about custom channel setup
find . -name "*.md" -o -name "*.txt" | xargs grep -l "自定义渠道\|Custom.*channel" 2>/dev/null | head -5

Length of output: 0

---

@seefs001

根据代码分析，我发现该PR的更改对某些现有自定义渠道存在兼容性问题，与PR描述的"向后兼容"说法不完全一致。

问题分析

更改前的行为（旧代码）：

func (a *Adaptor) SetupRequestHeader(...) error {
    // ... Azure处理 ...
    
    // 所有渠道类型（包括自定义渠道）都会设置默认Authorization
    header.Set("Authorization", "Bearer "+info.ApiKey)
    
    return nil
}
// 然后在api_request.go中应用Header Override

旧行为：自定义渠道即使没有配置Header Override，也会自动获得 Authorization: Bearer {api_key} 请求头。

更改后的行为（新代码）：

func (a *Adaptor) SetupRequestHeader(...) error {
    // ... Azure处理 ...
    
    // 自定义渠道完全跳过默认Authorization设置
    if info.ChannelType == constant.ChannelTypeCustom {
        return nil  // 直接返回，不设置任何Authorization
    }
    
    // 其他渠道类型才设置默认Authorization
    if !hasAuthOverride {
        header.Set("Authorization", "Bearer "+info.ApiKey)
    }
    return nil
}

新行为：自定义渠道必须通过Header Override显式配置Authorization，否则不会有任何Authorization请求头。

兼容性影响

✅ 不受影响的场景：

1. 已使用Header Override配置Authorization的自定义渠道 - 正常工作
2. 非自定义渠道类型 - 行为不变

⚠️ 会被破坏的场景：

现有的自定义渠道如果满足以下条件会受到影响：

• 没有配置Header Override
• 依赖系统自动设置的 Authorization: Bearer {api_key} 请求头
• 上游API需要标准的Bearer token认证

这些渠道在PR合并后将无法正常工作，因为它们不会再获得Authorization请求头。

建议方案

方案1：修改PR实现，保持完全向后兼容

if info.ChannelType == constant.ChannelTypeCustom {
    // 如果自定义渠道没有配置Authorization的Header Override，
    // 仍然设置默认值以保持向后兼容
    if !hasAuthOverride {
        header.Set("Authorization", "Bearer "+info.ApiKey)
    }
    return nil
}

方案2：添加迁移说明

如果接受这个破坏性变更，需要：

1. 在PR说明中明确标注这是breaking change
2. 提供迁移指南，要求所有自定义渠道用户添加Header Override配置：

   {
     "Authorization": "Bearer {api_key}"
   }

3. 考虑在版本更新说明中突出提示

方案3：数据库迁移脚本

为现有的自定义渠道自动添加默认Header Override配置。

您认为应该采用哪种方案？或者您有其他的考虑？

[Li-Xingyu]

我已经在本地环境进行测试，目前来看应该是没有问题？

[seefs001]

我已经在本地环境进行测试，目前来看应该是没有问题？

但是看你这个改动看样子会影响使用自定义渠道配置了在标准的key的字段里配置了key的用户

[Li-Xingyu]

好像明白了，我修改一下自定义渠道的逻辑

[Li-Xingyu]

应该ok了