Guidance on `login_not_required` for third-party views

Packages
1

I maintain a third party library that provides webhook callback views. I got a bug report that using Django’s LoginRequiredMiddleware (introduced in 5.1) breaks the webhooks.

Looking for some guidance on how third party packages are expected to handle LoginRequiredMiddleware:

  • Yes! Go ahead and apply login_not_required to any views that shouldn’t be subject to Django’s authentication (webhooks, alternative login and password reset pages, email unsubscribe links, etc.)
  • No! Using login_not_required in third party packages could introduce unexpected security issues. Developers wanting to use LoginRequiredMiddleware should carefully think through views where it shouldn’t apply, and then use the decorator only where they’ve determined it’s appropriate. (And maybe Django should mention that in the docs.)
  • There’s no one good answer. Because…?

(There was some earlier discussion in Add a Setting to Exempt URLs in `LoginRequiredMiddleware` - #4 by matthiask . From that, I think the answer is “Yes.” But I’d like to be sure.)

1 Like
2

I’d lean towards “Yes!” personally. The cases you gave shouldn’t require a login. I think if there are some views that a user may want to put behind a login, they can rework their urlpatterns to do that.

1 Like
3

The answer is a definite yes for the webhooks I know. All of them use a way of authenticating requests which isn’t tied to Django’s authentication (and session) system. Some of them only include the bare minimum and expect you to check back with the originating server, others include a cryptographic signature which you’re expected to calculate as well. I don’t know what Brevo does specifically but since you probably shouldn’t put a username/password combination into the Brevo webhook URL (and that would use basic authentication anyway for which Django doesn’t have any support out of the box) you can assume that the webhook URL should be available without Django authentication.

1 Like