Asyncifying django.contrib.auth? (and signals, and maybe sessions)

Hey @HappyDingning! Nice to meet you!

Yes there’s plenty to work on. I think your mention of AbstractBaseUser.check_password needing an async version is a good one that I didn’t even realize was needed. I haven’t looked to closely at the contents of AbstractBaseUser so perhaps a good place to start would be to analyze all the functions in that AbstractBaseUser and BaseUserManager and figure out which ones might need async versions (I know get_by_natural_key is a candidate for sure). Proposing that list of functions as a separate ticket (feel free to borrow phrasing from #34391 (Add async interface to contrib.auth) – Django) is a good first step. We’ll need an accepted ticket before you can move forward, feel free to CC me on the ticket!

Overall, my goal here is to asyncify the entire “stack” of the auth code, not just the interface (which is mostly covered by Fixed #34391 -- Added async interface to auth. by bigfootjon · Pull Request #16636 · django/django · GitHub and a hypothetical ticket for the User stuff I’m hoping you’ll work on). If you’re eager to help out with that larger goal then take a look at #3 in the original post on this thread. Basically, one of the prerequisites for full asyncification is making sure we can use the sessions system from an async context, ideally without sync_to_async wrappers. The first step here is to figure out what this would even look like (I would guess prefixing a bunch of I/O functions in the sessions system with “a” would be the first and maybe only step), so feel free to take a stab at figuring that out. I’m focused on driving the above PR to completion before I start working on the sessions issue myself, but I’m happy to help brainstorm and discuss!

1 Like