Related issue

Fixes #4297: "Private pages with group restrictions result in infinite loop between login url and target page"

Rationale

Currently, an authenticated user failing to pass a page (or document) view restriction based on their Group is redirected to the frontend login page. As documented in #4297, this can cause an infinite redirect loop. The expected behaviour would be to raise a PermissionDenied (403) exception.

However, just presenting an error screen is not always ideal - a better scenario might be to explain to users why they cannot access certain content (ie. "You must be a Stonecutter to access this page") - and so this PR also introduces a mechanism by which developers can specify a handler to deal with those requests.

Changes

• Adds WAGTAIL_UNAUTHENTICATED_GROUP_HANDLER and WAGTAILDOCS_UNAUTHENTICATED_GROUP_HANDLER as new settings
• Updates wagtail.wagtail_hooks.check_view_restrictions and wagtail.documents.wagtail_hooks.check_view_restrictions to check for existence of above settings pointing to handler methods, and falls back to raising django.core.exceptions.PermissionDenied for unauthorised users
• Updates unit tests
• Updates documentation

Questions

1. Currently check_view_restrictions checks for the existence of the new settings, and falls back to a PermissionDenied if they are not set. Does it make more sense for there to be default handler methods for WAGTAIL_UNAUTHENTICATED_GROUP_HANDLER and WAGTAILDOCS_UNAUTHENTICATED_GROUP_HANDLER in the Wagtail core (returning a PermissionDenied by default)?
2. Is it overkill to include a separate setting/method for documents (WAGTAILDOCS_UNAUTHENTICATED_GROUP_HANDLER)? If both hooks call WAGTAIL_UNAUTHENTICATED_GROUP_HANDLER, users could just be advised to provision for their handler to accept either a Page or Document as the first argument.
3. Does it still make sense to hard code the logic that non-authenticated users facing a group restriction are redirected to login, or should we allow developers to deal with this in their custom handler? Edit: Thinking about it some more, it would probably make sense to have this custom handler kick in before the default logic to redirect unauthorised users. This would allow a developer to attach a Django message to the request, for example. I guess this then raises the extra question of whether we should alllow for custom handlers for Restriction.LOGIN too...

Notes

The Docs CI seems to be failing based on an unrelated change in the 7.1 release notes:

Merged with upstream, so docs are now compiling 🎉