-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Add a config to forward user headers to litellm internal user #14423
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a config to forward user headers to litellm internal user #14423
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reviewed
_map_to_internal_user = False | ||
try: | ||
_map_to_internal_user = ( | ||
isinstance(general_settings.get("user_header_target"), str) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we not do it this way. Instead have a field called user_header_mappings like this: https://docs.litellm.ai/docs/proxy/token_auth#role-mapping-spec
then u can say
X-Open-Header: internal_user
X-Open-Email: end_user
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please also add validation that the value entered e.g internal_user, end_user is a valid role. We this defined in proxy/_types.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ishaan-jaff, should I make a backward-compatible change by keeping the existing field user_header_name behavior, or should I remove it because the user_header_mappings field will contain it?
user_header_mappings:
- header_name: X-OpenWebUI-User-Email
litellm_user_role: internal_user
- header_name: X-OpenWebUI-User-Email
litellm_user_role: external_user
Please make sure it’s backward compatible
Ishaan Jaffer
Co-Founder https://github.com/BerriAI/litellm
…On Wed, Sep 10, 2025 at 8:23 PM Boopesh Shanmugam ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In litellm/proxy/auth/auth_utils.py
<#14423 (comment)>:
> @@ -481,10 +481,22 @@ def get_end_user_id_from_request_body(
# and to ensure it's fetched at runtime.
from litellm.proxy.proxy_server import general_settings
+ # Config gate: If `general_settings.user_header_target == "internal_user"`,
+ # we should NOT use the forwarded header to populate End User.
+ # This ensures we don't duplicate the value into both Internal and End User fields.
+ _map_to_internal_user = False
+ try:
+ _map_to_internal_user = (
+ isinstance(general_settings.get("user_header_target"), str)
@ishaan-jaff <https://github.com/ishaan-jaff>, should I make a
backward-compatible change by keeping the existing field user_header_name
behavior, or should I remove it because the user_header_mappings field will
contain it?
user_header_mappings:
- header_name: X-OpenWebUI-User-Email
litellm_user_role: internal_user
- header_name: X-OpenWebUI-User-Email
litellm_user_role: external_user
—
Reply to this email directly, view it on GitHub
<#14423 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHASVM4I66PWVLRGRUJWHUL3SDTKDAVCNFSM6AAAAACGF2N5K6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTEMBYGUZTAMBRGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Upgraded PR is linked |
Title
Add a config to forward user headers to litellm internal user
Relevant issues
Pre-Submission checklist
Please complete all items before asking a LiteLLM maintainer to review your PR
tests/litellm/
directory, Adding at least 1 test is a hard requirement - see detailsmake test-unit
Type
🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test
Changes