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

Mentorship Google Season of Code
1

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

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

1 Like
2

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.