Is this line necessary? In my local build I was able to trigger the new error without it; I merely copied the pattern from the line above in my PR.

Good question; have you been able to understand this further?

This is following thisadvice from the Django docs:

Checks should be registered in a file that’s loaded when your application is loaded; for example, in theAppConfig.ready() method.

When you say you were able to trigger the new error without this: did this happen on startup, or when you rancheck manually?

I think I understand this better now.

The@register decorator causes the check function to be registered; all that's required beyond using the decorator is to arrange to load the module in which those functions live. That's why omitting this line still allows my check to be performed (on both startup, and when invoking thecheck management command manually, as it happens): the previous line causes the whole module to load, which causes not justpagination_system_check but my new check function to be registered as well.

I tested this theory by removingboth lines; in that case, my check doesnot run. But this means that both lines can be replaced with justfrom . import checks; that's sufficient to register all the check functions in that module.

I hope all this made sense 🙂. If it does, I'll plan to make that change and resolve this conversation.

Why isn't this a boolean, e.g.WWW_AUTHENTICATE_ALL = False (by default)?

I suppose I was leaving the door open for other modes beyond'first' and'all', but I think a boolean setting makes more sense here.

Setting name should be uppercase

RFC 9110 also warns:

Some user agents do not recognize this form, however. As a result, sending a WWW-Authenticate field value with more than one member on the same field line might not be interoperable.

Perhaps we should have a similar warning somewhere, either here or inauthentication.md.

Good question; have you been able to understand this further?

This probably should beTags.security, see for example all the checks inhttps://github.com/django/django/blob/0ee06c04e0256094270db3ffe8b5dafa6a8457a3/django/core/checks/security/base.py

Those checks also usedeploy=True, which causes them to only run withcheck --deploy. Not sure is this is a good idea. OTOH, it's done the same way for all the other validity checks for security settings.

I went withTags.compatibility largely because the other existing check is also looking to validate settings (which is all my check does, really).Tags.security seems to have more to do with actual security checks (rather than mere misconfiguration). Apparently it is also possible to omit the tag entirely.

I'm happy to go with any of these options, just let me know what you prefer.

Sure, I have no strong preference.