accessible to anyone who can log into your site at all
accessible if they have a password you enter on that form
That would seem like a fairly comprehensive list, but at work, we often
restrict things to anyone coming from specific IP addresses. So when
we rolled out our new CMS, we had requests for it to support the “on
campus” option - just like the old ones had.
Adding the “On Campus” option comes in two parts: adding it to the
options offered to the editor and then enforcing that restriction when
serving pages or documents.
Adding a New Restriction Choice
The privacy options are defined in the BaseViewRestriction class in
wagtail.core.models. We will be deciding if a browser is coming from
on or off campus with a middleware, so we will not have to add any columns
to the tables defined by classes inheriting from BaseViewRestriction.
But we do need to add “on campus” to the options offered to the site
To override the stock RESTRICTION_CHOICES from wagtail.core.models.BaseViewRestriction
with our own, we need to monkeypatch the class. We have a number of small
customizations in our wagtail site, so we collect them all into their own app,
wagtail_patches, which we include in INSTALLED_APPS.
And now the monkeypatching code:
That will add the ON_CAMPUS choice to our form. Since there are no additional
parameters needed for this restriction, you wouldn’t think we would have do
make any additional changes to the form or form validations. But as of Django 3,
we also need to patch the model level validations. We do that like this:
Enforcing Our New Restriction
In our setup, we have split enforcement into two parts, a middleware that
determines if a request is “on campus” or not and then code that uses that
information to show or not show the private page or file. We took this
approach beause we already have shared library that does the “on campus”
checking. If you do not need to share the code that checks for on vs off
campus, you may want to put that check directly into the code that enforces
On Campus Middleware
Define the following middleware somewhere in your project - customizing it
with your own IP addresses.
Then add this to the MIDDLEWARE list in your Django settings file. Since
this middleware is a silent pass through in both directions (only the side
effect of setting the ON_CAMPUS session variable to True or False matters),
you can put this line anywhere in the list.
Updating the Enforcement Code
The meat of the restriction enforcement is in BaseViewRestriction’s accept_request
method, so we need to add our new on-campus check:
What should happen when accept_request returns False? That depends on which
restriction triggers the failure. For example, if a user fails the LOGIN restriction,
they should be directed to log in - but if they fail the ON_CAMPUS restriction,
they should get an error message. The correct actions for the built-in
restriction types are handled in a before_serve_page hook called
Since we already have monkey patched some other hooks, what we did was
to monkey patch check_view_restrictions:
But looking at the source code for the page serve view, I don’t think
we need to replace the existing check_view_restrictions. I think we
can just add an additional before_serve_page hook that returns our
“sorry you need to be on campus to see this page” message. If I were
doing this from scratch, I would put the following code into one of my
wagtail_hooks.py files (either in the wagtail_patches app or in that
app that contains most of my page models).