-
Notifications
You must be signed in to change notification settings - Fork 798
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add private sites module #10333
Add private sites module #10333
Conversation
This is an automated check which relies on |
e87aa1c
to
c7139f9
Compare
This is a cool and really useful feature. It'll be nice to get it integrated, especially so that WordPress.com will have more complete information about what sites are private (right now, we do some little heuristics checks to get partial information). For v1, I don't think we should worry about invites/members, feed authentication, or privatizing links. I think the main focus should be getting something simple in place that locks everything down (requiring authentication for normal blog views, REST API, OPML, etc., an appropriate robots.txt response, …). It'd be nice to get a list of what's important first. I haven't tested this PR, but I'm reasonably certain that much of the more complicated stuff (particularly invites) will not be fully functional as written outside of the WordPress.com infrastructure. Besides trimming this down to an MVP, another alternative would be to point people at an existing privacy plugin. That might cause us backward-compatibility headaches in the future (though I don't think it would be too bad), and could be an "easy" (ha!) work-around for whatever is blocked by the lack of private sites in Jetpack. |
In terms of something existing, we often suggest https://wordpress.org/plugins/registered-users-only/ to folks by @Viper007Bond. It'll lock down just about everything, but could be smoother with REST requests. |
This PR looks like it might contain user tracking functions. We need to make sure that it is GDPR Compliant. Rules triggering this positive scan:
cc: @pesieminski |
4275a3a
to
ed26f64
Compare
This PR looks like it might contain user tracking functions. We need to make sure that it is GDPR Compliant. Rules triggering this positive scan:
cc: @pesieminski |
ed26f64
to
d03b99c
Compare
This PR looks like it might contain user tracking functions. We need to make sure that it is GDPR Compliant. Rules triggering this positive scan:
cc: @pesieminski |
I noticed |
The file was removed from Jetpack a little while ago, so it may be a rebase gone wrong? Either way, the file should indeed be removed from that PR. |
d03b99c
to
c345142
Compare
This PR looks like it might contain user tracking functions. We need to make sure that it is GDPR Compliant. Rules triggering this positive scan:
cc: @pesieminski |
@brbrr yes, sorry a rebase gone wrong. fixed now. |
This PR looks like it might contain user tracking functions. We need to make sure that it is GDPR Compliant. Rules triggering this positive scan:
cc: @pesieminski |
I updated this to conform to the WordPress coding standards. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a few notes that hopefully will help a bit.
modules/private.php
Outdated
update_option( 'blog_public', 1 ); | ||
} | ||
|
||
add_action( 'parse_request', 'privatize_blog', 100 ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this enough to make sure we block access to RSS feeds, Core's REST API, and WordPress.com's REST API requests for that site?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to block the Core REST API. I guess we don't need to do that for the WordPress.com REST API as this module won't be enabled on WPCOM, since we have a different one there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as the Jetpack site is connected to WordPress.com and the JSON API module is active in Jetpack (it's enabled by default and there is no easy way to deactivate it, the UI is hidden), the site's content will be available via the WordPress.com REST API. Here is an example:
https://public-api.wordpress.com/rest/v1.1/sites/53262711/posts/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like they are already blocked in the WPCOM REST API:
b6781b0
to
7b6a5cf
Compare
scruffian, Your synced wpcom patch D27234-code has been updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a few nitpicks inline.
The "At a Glance" dashboard widget is confusing in one state:
- Make sure your site is public.
- Go to wp-admin/ → Settings → Reading.
- For "Site Visibility", check "Discourage search engines from indexing this site".
- Click "Save Changes".
- Go to wp-admin/ → Jetpack → Settings → Security.
- For "Private site", check "Make your site private"
- Go to wp-admin/ (→ Dashboard)
- Look at the "At a Glance" widget. See:
This site is set to private. Make public.
Search Engines Discouraged
… to WP_Error error code
…essage from At a glance dashboard 2. Adds a line break preceeding the 'Search engines are discouraged message'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tests well for me, looks good. Let's merge this and get Beta testers to take a crack at it!
* Kick off the changelog * Add 7.3.1 * Update date and post link * changelog: add #12219 * changelog: add #12170 * changelog: add #12184 * Changelog: add #12268 * Changelog: add #12081 * Changelog: add #12323 * Changelog: add #12204 * Changelog: add #12269 * Changelog: add #12332 * changelog: add #12339 * changelog: add #12209 * Changelog: add #12319 * Changelog: add #12357 * Changelog: add #12124 * Changelog: add #12373 * Changelog: add #12252 * Changelog: add #12383 * Changelog: add #12372 * changelog: add #12337 * Changelog: add #12290 * Changelog: add #12301 * Changelog: add #12061 * Testing list: add instructions for #12061 * Changelog: add #12393 * Update minimum supported version See #12287 * Changelog: add #12406 * Testing list: add #12406 * Changelog: add #12277 * Changelog: add #12412 * Changelog: add #11318 * Changelog: add #12328 * Changelog: add #12425 * Changelog: add #12380 * Changelog: add #12428 * Changelog: add #12414 * Changelog: add #12395 * Changelog & Testing list: add #12416, #12417, #12418, and #12348 * changelog: add #12379 * Changelog: add #12341 * changelog: add #12444 * Changelog: add #12434 * Changelog: add #12454 * Changelog: add #12460 * Changelog: add #12463 * Changelog: add #12457 * Changelog / testing list: add #10333 * Changelog: add #12467 Co-authored-by: Jeremy Herve <jeremy@jeremy.hu>
This adds a "Private site" module to Jetpack. The code is based on a similar plugin from WordPress.com.
Fixes #7857
Internal reference: p5XAZ9-1Pk-p2
Changes proposed in this Pull Request:
Testing instructions:
Scenario 1
Site Visibility
option appears disabled for private sitesVisit your site, you should still be able to see it
Visit your site in an incognito window, you should see this:
Create a new user on your site (with any role). Log in as this new user. You should be able to see the site.
Update this user to have no role on this site. Now you should see this:
At a glance
dashboard widget shows that the site is privateScenario 2