View restrictions for collections

Based on the view restrictions for pages I implemented the view restriction for collections too. If someone only serves the documents and images with the serve view functions from wagtaildocs and wagtailimages they are fully protected.
Some problems still exists because documents and images are normally saved in the media folder and so they can be accessible from the webserver.
I'm open for advice how to solve the remaining problems.

Is this going to be integrated in a future release?

Rebased on latest master and cleaned up at https://github.com/gasman/wagtail/tree/viaregio-viewrestrictions

Thanks @viaregio!
A few changes I propose to make here:

Leave out the image serving logic - it doesn't really fit with the rest of the functionality, since users don't visit images like they visit pages or documents. This also simplifies some of the remaining code (e.g. rather than a before_serve_from_collection hook that gets caught within wagtailcore and has to support both images and documents, it can be a before_serve_document hook handled entirely within wagtaildocs).
Don't make the Collection model responsible for serving the 'password required' response. This logic exists on pages so that we can customise the output for specific page types - e.g. show the intro paragraph followed by a "register to read the rest of the article" panel. There's no equivalent thing we can do for documents, and no way for users to subclass Collection, so we should skip straight to the PASSWORD_REQUIRED_TEMPLATE case.
The collections/edit.html template should extend generic/edit.html (adding new overrideable blocks if necessary) - the collections admin interface was the first real use of the generic views/templates in wagtailadmin, and we hope to port more of Wagtail's admin views to use them in future, so it's important that the collection edit view follows best practices in re-using that template code.

The intention of this pull request is to allow for a setup with "non public" pages and collections. My understanding of a "non public" collection is a collection with documents and images that are only served to visitors after some kind of authorization.
If the image serving logic is omitted no images can be served from such a collection. To protect the users from accidentally serving images to users without some kind of authorization this would mean that such collections must not contain any images. I'm not very keen on this because public collections can contain documents and images.

If the image serving logic is omitted no images can be served from such a collection.

That's not really true - if the image serving logic is omitted, then all image renditions (regardless of collection) will have public URLs, so they'll continue to work exactly as they do now.
Unfortunately, image handling in Wagtail is a messy subject because there are lots of conflicting demands and opinions on how it should work:

whether renditions should be generated in advance, or at the point of being used on a template, or at the point of being requested
whether users should be able to request arbitrary renditions, or be locked down to the ones chosen by the developer
whether to allow the "create a rendition from an image" step to be skipped (e.g. to support SVG images, or avoid recompression of images that were already optimised before uploading to Wagtail)
whether it's best to host images and renditions locally or on remote storage such as S3
how to deal with caching

Some of these problems have partial solutions, such as the dynamic image serve view - others are still waiting to be solved.
With this change, we're introducing the possibility of renditions being served via Django, which adds a whole new dimension of complexity. It's going to take a lot of work to make sure that it works correctly with all of those other moving parts, and I really want to avoid shipping a "half-baked" solution where we have to tell users: "Access control on images doesn't work out of the box. You can enable it by setting up RenditionServeView... but that won't work if you're using remote file storage. And on a high traffic site you'll need to make sure sendfile is configured on your webserver, or else the extra Django threads will probably kill it. And we're not sure how to make it work with a frontend cache..."
There's currently a lot of demand for Wagtail to support access control on documents, so I think it's best that we ship a document-only solution as soon as possible, and tackle images separately as a future development.

That's not really true - if the image serving logic is omitted, then all image renditions (regardless of collection) will have public URLs, so they'll continue to work exactly as they do now.

In my opinion this is exactly the problem that needs to be solved. As user of the protected collection I would assume that images uploaded to this collection are protected and have NO public URLs. To get images with public URLs I could upload them to non protected collections already.
If images can't be protected by uploading to protected collections they shouldn't be allowed in protected collections.

@viaregio If this is a concern, we can update the message when setting up collection permissions to make it clear that they only apply to documents, not images.
I don't think we'll ever be able get RenditionServeView to a point where it's possible to enable it by default for everyone (including high-traffic sites using remote storage / CDNs), and so the potential for user error (i.e. content editors assuming that collection permissions will protect images, when really they don't) will still exist for sites that don't have RenditionServeView configured. I think it's safer for us to not promise image protection as a feature, rather than provide an implementation that only works on certain configurations.

Updated version now opened as PR #3644.


Migrate deployment to github pages

I'm starting to reach higher percentages of my free dyno hours on heroku, so I thought it might be a good idea to move towards a different free hosting solution for the static webapp. This should free up enough hours to continue running the api.

Closed by #82


TypeError: Cannot read property 'pipe' of undefined

My code is same as in issue #201.
For a different input of body.refpages, there are 229 snapshots to be fetched.
I get this error:
[TypeError: Cannot read property 'pipe' of undefined]
Got screenshot at:<PHONE_NUMBER>515
/Users/rahul/backlink-checker/node_modules/pageres/node_modules/each-async/node_modules/onetime/index.js:15
				throw new Error(fnName + ' can only be called once.');
				      ^
Error: callback() can only be called once.
    at /Users/rahul/backlink-checker/node_modules/pageres/node_modules/each-async/node_modules/onetime/index.js:15:11
    at Pageres.<anonymous> (/Users/rahul/backlink-checker/node_modules/pageres/index.js:119:3)
    at Immediate.immediate._onImmediate (timers.js:409:16)
    at processImmediate [as _immediateCallback] (timers.js:358:17)

Any idea why?

Can you upgrade to the latest pageres version and try again?


Ranks.yml got replaced with fresh file after (i assume) a config error

Describe the bug
Create a config error in ranks.yml removes the ranks.yml file and creates a new clean one.
All custom configurations are lost and i have to manually redo them again.
To Reproduce

Create config error in prestige part of ranks.yml.
reboot server
observe the new ranks.yml

Expected behavior
if an error occurse while booting the server. output that error on the console and dont remove my files. its weird and an uncommon practice if a plugin replaces customized files.
Screenshots
https://pastebin.com/EgxT3wJv
Running Paper version git-Paper-783 (MC: 1.16.5) (Implementing API version 1.16.5-R0.1-SNAPSHOT)
java v16.02

check the expected , but found '-' line
in 'string', line 207, column 5: in ranks.yml you are making a mistake, for sure you put wrong use
https://codebeautify.org/yaml-validator


set fake shared env as failed when a test fails

some of the cleanup functions check for Failed() when determining cleanup behavior. an example of this is the kind cluster cleanup, where the cluster is preserved if Failed() is true and the debug flag is provided. this change makes it so that such cleanup blocks can honor the --debug flag for shared kind environments.

/assign @karlkfi


FIX : Missing Navbar added

Description
Missing Navbar is added to the book now page.
Related Issues

Closes #781

Type of PR

[x] ( Bug Fix )

Screenshots / videos (if applicable)
Before

After

Checklist

[x] I have gone through the contributing guide
[x] I have updated my branch and synced it with project main branch before making this PR
[x] I have performed a self-review of my code
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x] I have commented my code, particularly in hard-to-understand areas.

Additional context:

Please review and merge this PR.


test/crltest.c: Add check for glue2bio

As the glue2bio() could return NULL pointer if fails,
it should be better to check the return value in order
to avoid the use of NULL pointer.
Signed-off-by: Jiasheng Jiang<EMAIL_ADDRESS>
Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

The CI failure is relevant. You cannot intermix declarations and code.

The CI failure is relevant. You cannot intermix declarations and code.

Thanks, I have corrected the problem.

This pull request is ready to merge

Merged to 3.0 and master, thanks for the fixes.