Description

@carljm is working on it: "I did work on updating decorator_from_middleware yesterday and have an in-progress patch. I don't think we should plan on the patch for alpha (it's nontrivial and will need review), but if it's ok to do it as a follow-up cleanup fix for beta, then yeah I think it's be good to have it for 1.10.

Oldest firstNewest firstThreaded

Show commentsShow property changes

Change History (5)

Absent a compelling use case for this update and due to some limitations in how effectively decorator_from_middleware can make the transformation, we decided not to move forward with this. A query about it has been raised ​on Reddit. I've asked if that poster can give a use case here.

Of course, I could craft my own get_response, initiate the middleware and call __call__ or process_exception directly but that is ugly and easy to get some details wrong, especially when the test involves exceptions.

We have a custom authentication mechanism that is not tied to contrib.admin for our main site.

However, we use contrib.auth for administrative accounts. To make it very clear which views needs a real user, we have disabled the auth middleware globally and use a custom admin site that selectively enables auth:

(This use case is fine and works fine in Django 1.10 since Django's built in AuthenticationMiddleware is both old and new-style, but I just wanted to highlight that decorator_from_middleware is useful in different contexts)