does the Protect module still reliably protect the entire network?
No, it will only protect the sites where Protect is enabled.
Or are the login and xmlrpc access points on these sites without Protect activated unprotected?
Jetpack Protect doesn’t protect your XML-RPC file yet. It only affects the log in page, when the Protect module is enabled on the site.
does the use of a Domain Mapping plugin affect things further?
No, that won’t affect the way Protect works.
Is there any way to force the activation of Protect on all sites in the network, even if Jetpack is not connected by individual site admins?
I’m afraid not. Protect will be activated as soon as the site admins (or you, via the Jetpack menu in Network Admin) connect Jetpack to WordPress.com, but if a site is not connected to WordPress.com Protect won’t work.
I hope this clarifies things a bit.
Salut Jeremy, yes that clarifies a lot thanks!
So will it be better to leave Bruteprotect running network activated? And if so, do Bruteprotect and the new Jetpack Protect hinder each other in any way?
And one final question: are XML-RPC protection and network-wide planned for the (near) future?
So will it be better to leave Bruteprotect running network activated? And if so, do Bruteprotect and the new Jetpack Protect hinder each other in any way?
You could do that, and you won’t run into any conflicts as long as you keep the Protect module deactivated, but we probably won’t be maintaining the old BruteProtect plugin for much longer I’m afraid.
And one final question: are XML-RPC protection and network-wide planned for the (near) future?
We do plan on bringing more security features to Jetpack in the future, indeed.
For network-wide protection, on the other hand, I’m afraid you will need to connect each sub-site to WordPress.com for now. Another Jetpack user suggested a network-wide protect configuration screen, though, and I added your vote to the GitHub issue:
https://github.com/Automattic/jetpack/issues/1861
That is a major problem since the last update.
Jetpack is leaving all other sites beyond the main vulnerable. We have already suffered some major effects.
Something has gotten mixed up!
Your siteurl option is set up as http://sxxxxxxx.com, but your WordPress.com connection lists it as http://www.xxxxxxxxx.com!
Your home option is set up as http://xxxxxxxxxx.com, but your WordPress.com connection lists it as http://www.xxxxxxxx.com!
The data listed above is not for my current site. Please disconnect, and then form a new connection to WordPress.com for this site using my current settings.
Ignore the difference. This is just a staging site for the real site referenced above.
That used to be my URL for this site before I changed it. Update the WordPress.com Cloud’s data to match my current settings.
Settings
… I added your vote to the GitHub issue:
https://github.com/Automattic/jetpack/issues/1861
Thanks 🙂
… we probably won’t be maintaining the old BruteProtect plugin for much longer I’m afraid.
I was quite happy with the news that Bruteprotect was bought by Automattic and going to be integrated into Jetpack but now not so much anymore. Will there be a large window between ending the Bruteportect service and imprlementing any sort of network wide Jetpack Protect feature?
@sanfam – why do you think the “Something has gotten mixed up!” message is related to the Protect module? I’ve got these messages too across the network but I assumed they are related to the use of Domain Mapping. Using WPMUDEV’s Domain Mapping before, I switched to Donncha’s Domain Mapping and the messages have disappeared. However, the underlying issue has not, I think. The issue being the descrepancy between the registered domain name at WordPress.com and the domain name used on the front end of the site itself. For instance, Publicize will use the original domain instead of the mapped domain which many site admins don’t like very much.
Will there be a large window between ending the Bruteportect service and imprlementing any sort of network wide Jetpack Protect feature?
I don’t have an ETA yet I’m afraid. That will probably depend on the number of people interested in the feature.
I’d suggest that you keep an eye on the GitHub issue, we’ll post there as soon as we make progress.
@sanfam I think we’ve already discussed this issue in the other thread you started a few days ago:
https://wordpress.org/support/topic/jetpack-not-working-well-on-multisite-after-upgrade
Do not hesitate to post again there if you have more questions!
