# GSoC 2026 Contributor Introduction + Proposal: Fix Client.login() middleware (#15179)

**URL:** <https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-proposal-fix-client-login-middleware-15179/44595>\
**Category:** Google Season of Code\
**Created:** [March 19, 2026, 10:44am UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-proposal-fix-client-login-middleware-15179/44595 "2026-03-19T10:44:47Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![its-me-maady](https://avatars.discourse-cdn.com/v4/letter/i/6a8cbe/32.png) [@its-me-maady](https://forum.djangoproject.com/u/its-me-maady)\
**Post date:** [March 19, 2026, 10:44am UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-proposal-fix-client-login-middleware-15179/44595/1 "2026-03-19T10:44:47Z")

</div>

Hi everyone,

I’m Maadhesh S, a self-taught Python developer from Madurai, Tamil Nadu, currently in my second year of B.E. Computer Science at Vaigai College of Engineering (2023–2027). I’ve been writing Python since school and have built Flask web apps, CLI tools, and algo-trading experiments. I work daily on Arch Linux with Neovim and am comfortable reading source code and docs without tutorials.

**Proposed Project: Fix Client.login() middleware handling — Ticket #15179**

**Problem** `django.test.client.Client.login()` constructs a fake `HttpRequest` that never passes through the middleware stack. This means any authentication backend that relies on request metadata (like `HTTP_HOST`, custom headers, or middleware-set attributes) behaves differently during tests versus production — silently, with no error.

**History** I’ve read the full comment history on this ticket. A fix by Unai Zalakain was merged into Django 1.7 but reverted before release because it did a full request/response cycle against the user’s actual views — causing test failures when the root URL view wasn’t set up in the test database. loic84’s proof-of-concept in comment:37 identified the correct approach: route the login request through a dedicated internal dummy view using a custom `urlconf` override, so middleware runs on a proper request without coupling to user-defined views.

**Proposed Approach** Implement and modernise loic84’s design for Django 6.1:

- Override `urlconf` inside `Client.login()` to point to a minimal internal dummy view

- Pass the request through the full middleware chain using `Client`’s existing `handler`

- Respect `Client` defaults (e.g. `HTTP_HOST`) set at instantiation

- Maintain full backwards compatibility

- Write regression tests covering the original reported failure case

**About Me**

- GitHub: [its-me-maady (Maadhesh) · GitHub](https://github.com/its-me-maady) (Flask alumni portal, ToDo CLI, Markdown→HTML parser, algo-trading experiments)

- Email: [maadhesh.off@gmail.com](mailto:maadhesh.off@gmail.com)

I’d really appreciate feedback on the proposed approach before I finalize the proposal — particularly whether the dummy urlconf direction is still the right one given `force_login()` was added in 1.9, and whether this scope is appropriate for a 175hr or 350hr project.

Thanks for your time! Maadhesh

---

<div class="post-metadata">

**Author:** ![its-me-maady](https://avatars.discourse-cdn.com/v4/letter/i/6a8cbe/32.png) [@its-me-maady](https://forum.djangoproject.com/u/its-me-maady)\
**Post date:** [March 25, 2026, 1:32am UTC](https://forum.djangoproject.com/t/gsoc-2026-contributor-introduction-proposal-fix-client-login-middleware-15179/44595/2 "2026-03-25T01:32:57Z")

</div>

Bumping this with a more specific question:

For the fix, I’m leaning toward loic84’s dummy urlconf approach from the ticket — creating a minimal urlconf that includes the middleware stack so Client.login() actually runs through it. Given that force\_login() was added in Django 1.9 as a bypass, does it still make sense to fix login() itself, or is the intended path to just document force\_login() as the alternative?

Also happy to scope this as a 175hr project focused purely on the login() fix + tests, without touching force\_login() behavior. Would that scope work for GSoC, or is there a broader set of changes you’d want included?

Thanks.