litellm - ✅(Solved) Fix [Docs]: document enable_post_custom_auth_checks and its interaction with custom_auth_run_common_checks [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#25862Fetched 2026-04-17 08:28:34
View on GitHub
Comments
1
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
referenced ×2commented ×1cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #25863: docs(proxy): document enable_post_custom_auth_checks for custom auth

Description (problem / solution / changelog)

Relevant issues

  • Closes #25862

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have Added testing in the tests/test_litellm/ directory
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem
  • I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Notes:

  • This is a docs-only PR. It does not change runtime behavior.
  • I did not mark the testing items complete because I only updated proxy documentation.

Summary

The current proxy docs mention custom_auth_run_common_checks, but they do not document the outer enable_post_custom_auth_checks gate that actually enables LiteLLM's post-custom-auth validation flow.

That creates a docs gap for operators using custom auth:

  • the code and tests make the opt-in behavior explicit
  • the published docs only mention the inner custom_auth_run_common_checks flag
  • readers can incorrectly assume the inner flag is sufficient on its own

Type

📖 Documentation

Changes

  1. Add enable_post_custom_auth_checks to docs/my-website/docs/proxy/config_settings.md

    • documents the flag
    • documents the default (false)
    • explains that the default is performance-oriented
  2. Add a short explanation to docs/my-website/docs/proxy/custom_auth.md

    • shows how enable_post_custom_auth_checks interacts with custom_auth_run_common_checks
    • explains which built-in checks run when post-custom-auth checks are enabled
    • makes it explicit that custom_auth_run_common_checks only has an effect inside the post-custom-auth flow

Screenshots / Proof of Fix

Docs-only change.

Proof from current code/docs state before this PR:

  • litellm/proxy/auth/user_api_key_auth.py gates _run_post_custom_auth_checks(...) behind enable_post_custom_auth_checks
  • docs/my-website/docs/proxy/config_settings.md documented custom_auth_run_common_checks but not enable_post_custom_auth_checks

After this PR:

  • both docs pages describe the opt-in flag and its interaction with the common-check flag
  • no runtime behavior changes

Changed files

  • docs/my-website/docs/proxy/config_settings.md (modified, +1/-0)
  • docs/my-website/docs/proxy/custom_auth.md (modified, +24/-0)
RAW_BUFFERClick to expand / collapse

What happened?

The proxy docs currently document custom_auth_run_common_checks, but they do not document the outer enable_post_custom_auth_checks gate that controls whether LiteLLM runs post-custom-auth validation on UserAPIKeyAuth objects returned by custom auth handlers.

In current code, the custom-auth return path only runs _run_post_custom_auth_checks(...) when enable_post_custom_auth_checks is truthy:

  • litellm/proxy/auth/user_api_key_auth.py lines around the user_custom_auth / enterprise_custom_auth return path

The existing docs/config table mention:

  • custom_auth_run_common_checks

but do not explain that:

  • enable_post_custom_auth_checks exists
  • it defaults to false
  • custom_auth_run_common_checks only has an effect inside the post-custom-auth flow

Why this is a problem

For operators using custom auth, the current docs make it easy to assume that setting custom_auth_run_common_checks: true is sufficient.

In practice, if enable_post_custom_auth_checks is left unset, LiteLLM will stay on the fast path and skip the post-custom-auth validation step entirely.

That creates an avoidable docs / operability gap between:

  • current runtime behavior
  • test coverage / code comments
  • published proxy configuration docs

Expected behavior

The docs should explicitly describe:

  1. enable_post_custom_auth_checks
  2. its default (false)
  3. the built-in checks it enables
  4. that custom_auth_run_common_checks only applies when post-custom-auth checks are enabled
  5. the performance tradeoff / why the default is opt-in

Suggested fix

  • Add enable_post_custom_auth_checks to docs/my-website/docs/proxy/config_settings.md
  • Add a short section to docs/my-website/docs/proxy/custom_auth.md showing how it interacts with custom_auth_run_common_checks

I already have a small docs-only PR prepared for this and can link it once opened.

extent analysis

TL;DR

Update the proxy documentation to include enable_post_custom_auth_checks and its interaction with custom_auth_run_common_checks to reflect the actual runtime behavior.

Guidance

  • Review the current documentation for custom_auth_run_common_checks and update it to mention the requirement for enable_post_custom_auth_checks to be truthy for post-custom-auth validation to occur.
  • Add a new section to the documentation to explain the purpose and default value of enable_post_custom_auth_checks, as well as its performance implications.
  • Ensure that the documentation clearly states that custom_auth_run_common_checks only applies when enable_post_custom_auth_checks is enabled.
  • Verify that the updated documentation accurately reflects the code's behavior, particularly in litellm/proxy/auth/user_api_key_auth.py.

Example

No code snippet is necessary for this issue, as it is primarily a documentation update.

Notes

The fix is limited to updating the documentation to match the current code behavior. This change does not affect the runtime behavior of the application but rather improves the accuracy and completeness of the documentation.

Recommendation

Apply the suggested fix by updating the documentation as described, to ensure that operators using custom auth have a clear understanding of the requirements and implications of using custom_auth_run_common_checks and enable_post_custom_auth_checks.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The docs should explicitly describe:

  1. enable_post_custom_auth_checks
  2. its default (false)
  3. the built-in checks it enables
  4. that custom_auth_run_common_checks only applies when post-custom-auth checks are enabled
  5. the performance tradeoff / why the default is opt-in

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

litellm - ✅(Solved) Fix [Docs]: document enable_post_custom_auth_checks and its interaction with custom_auth_run_common_checks [1 pull requests, 1 comments, 1 participants]