Should we try to fix the issue with the newLoginRequiredMiddleware as part of this PR?#9503

Should we try to fix the issue with the newLoginRequiredMiddleware as part of this PR?#9503

I think we should include that in this PR

I initially went with a customLoginRequiredMiddleware but then realised that authentication status of a request in DRF isn't easy to figure out at the middleware level. This is because it's a combination ofauthentication_classes +permission_classes settings, which may come from the view or the global settings.

Additionally, I struggled a bit to test that solution as I couldn't find out a way to configure test views with a non-defaultDEFAULT_PERMISSION_CLASSES, and I always ended up withAllowAny in my views. I was aiming for integration style of tests: configuring a view, with URLs and setting up the whole middleware chain. I left the commit if someone is interested...

I took a step back and realised that DRF already offered a way to achieve whatLoginRequiredMiddleware does, via its settings. So I ended marking DRF views as opted-out from Django's middleware, and documenting how to achieve the same thing with API views.

What do people think of the approach?

Very nice solution. I feelLoginRequiredMiddleware is intended for 'normal' Django views, not for API calls.
Thank you very much for making this change.

Added some more integration-like type of tests to make sure every type of views are covered: class based views, function based views, viewsets and viewsets actions.

Is there a plan to make a new release to PyPI soon with this change? Debian is currently in the process of switching to Python 3.13 by default, which either requires Django 5.1 or some backporting of patches. I'm wondering whether it makes more sense to attempt to backport this patch to REST framework 3.15.2, or something else.