fix: guard SQLite int(sub) against large OAuth subs (closes #29048)

[lesbass]

Description

Google OAuth login fails on SQLite with Python int too large to convert to SQLite INTEGER because Google's 21-digit sub claim exceeds SQLite's signed 64-bit INTEGER range (~9.2e18). The get_user_by_oauth_sub() method unconditionally calls int(sub) for any decimal SQLite sub, causing an OverflowError during SQLAlchemy query binding.

Fix

Added a len(sub) <= 18 guard to the SQLite int(sub) path in backend/open_webui/models/users.py:369. This ensures:

• Large subs (e.g. Google's 21-digit sub): only the string comparison is used — no int() conversion
• Small numeric subs (e.g. GitHub user IDs ≤18 digits): still get the int() comparison for type-matching against stored JSON numerics
• Postgres: completely unaffected (the SQLite-only branch is not entered)

Verification

• 5 regression tests pass covering: 21-digit Google sub (no int path), 8-digit GitHub sub (int path), 18-digit max-safe sub, 19-digit overflow sub, and non-decimal sub
• Ruff lint confirms no new lint errors introduced (8 pre-existing errors in the file are unrelated)
• Single-line diff: 1 file changed, 1 insertion, 1 deletion

Related

• Closes issue: Google OAuth login fails on SQLite — "Python int too large to convert to SQLite INTEGER" (21-digit Google sub) #29048
• Related to upstream issue: issue: Google OAuth login fails on SQLite — "Python int too large to convert to SQLite INTEGER" (21-digit Google sub) #29048

---

Changelog Entry

Fixed

• Google OAuth login no longer crashes on SQLite when the provider returns a large (21-digit) sub claim

---

Contributor License Agreement

• By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.