After migrating a Wagtail-based site from MySQL to Postgres, we
noticed that malicious requests to the site that included percent-
encoded Unicode NULLs (`%00`) raised a `ValueError` exception that we
hadn't seen when using MySQL: `A string literal cannot contain NUL
(0x00) characters.` This appears to relate to `psycopg2`'s decision to
raise an exception in these situations, as discussed here:
https://github.com/psycopg/psycopg2/issues/420
While newer versions of Django appear to provide some field validation
that addresses these characters, it doesn't look like Wagtail's
redirect middleware is making use of those validators, and so it seemed
reasonable to clean these characters in the context of 'normalizing'
the paths before looking for corresponding redirects -- especially
since a quick investigation on the internet suggests that U+0000 in
URLs can be used as a means of attack, and also since RFC 3986 says:
Note, however, that the "%00" percent-encoding (NUL) may require
special handling and should be rejected if the application is not
expecting to receive raw data within a component.
Fixes #4424. As of #3354, `get_url` is the preferred way of obtaining a page URL, rather than the `.url` property;
.url is just a wrapper around get_url (which meant that the docstring for `get_url` was erroneously being picked up).
We currently index all items in Elasticsearch using the root bulk api
(at ``/_bulk``). This API is to allow multiple indices to be inserted
into at once. However, Wagtail inserts into one index at a time so this
is not needed. If we pass the index name as a parameter in the call to
``bulk()``, the index-specific bulk API will be used instead (at
``/<index name>/_bulk``.
The advantage of this change is it makes it possible to implement access
control by checking the URL an application is using. This is required in
order for the Bulk API to work on certain hosts (such as Divio).
* Expose Draftail package as global variable for reuse
* Expose Wagtail React components for reuse
* Expose Draftail-related React components for reuse
This change prevents non-admins from navigating around the Wagtail page
tree for pages that lie outside of their explorable root. Currently,
non-admins can hit any page in the tree using a URL like
/admin/pages/123/
even if they don't have any permissions over that page or its part of
the page tree.
This change adds a (temporary) redirect to requests like this, so that
users may not navigate to parts of the tree that lie outside outside of
their explorable site root, as determined by the page privileges they
have. If they try to hit a URL like the one above, they get redirected
to their explorable site root navigation page instead.
Relevant unit tests have been modified to incorporate this change.
This change modifies how the Wagtail home site summary panel displays
the number of pages on the site, and where that number links to.
Instead of showing the total number of pages on the site, the panel
should show the number of pages under the user's explorable root page
(inclusive). If the user has access to the full tree, the Wagtail root
is not counted in this total.
Previously, the site summary page link would go to the Wagtail root if
there were multiple sites in an installation, and to the site root page
for a single site. This change modifies this logic so that the link
always goes to the user's explorable root page (which may be their
explorable root page).
The unit tests for the site summary panel have been pulled out into a
new module at `wagtail.admin.tests.test_site_summary`, and augmented to
test how things work for users with different permissions.
This implements a new "find" view for all endpoints which can be used
for finding an individual object based on the URL parameters passed to
it.
If an object is found, the view will return a ``302`` redirect to detail
page of that object. If not, the view will return a ``404`` response.
For the pages endpoint, I've added a ``html_path`` parameter to this
view, this allows finding a page by its path on the site.
For example a GET request to ``/api/v2/pages/find/?html_path=/`` will
always generate a 302 response to the detail view of the homepage. This
uses Wagtail's internal routing mechanism so routable pages are
supported as well.
Fixes #4154
Searching the docs for the phrases "add django model to wagtail admin" and "add model to wagtail admin" (without the quotes) did not even yield this crucial page as one of the results. The proposed wording puts the main idea of being able to show/edit ANY model via the Wagtail admin at the top of the document and includes wording to, hopefully, have this page appear at the top for anyone searching for how to implement this functionality.
* Add a new hook 'register_account_menu_item'
This new hook makes it easier for third party apps to add new buttons on
the 'my account' page in the Wagtail admin. Existing buttons are
converted to the new hooks to make the code consistent.
* Add documentation for the new register_account_menu_item hook
(technically we should standardise on no leading space, because the leading space creates a blockquote element - however, it's not really noticeable in the end result, and this way we can easily copy and paste from the changelog...)
