Hi all!
Hostgator have enabled mod_security and disabled any way for the users to disable it. One of the rules that Apache's mod_security looks for is http:/ in the form data (GET or POST).
When enabling Jetpack plugin, after giving the authorization on Wordpress.com, I'm being redirected to:
http://<site>/wp-admin/admin.php?page=jetpack&action=authorize&_wpnonce=<token>&redirect=http%3A%2F%2F<site>%2Fwp-admin%2Fadmin.php%3Fpage%3Djetpack&code=<code>&state=1
Because of the http:/ in the redirect parameter, mod_security kills the page and throws a 403 error. However, if I just remove the http:// and try accessing:
http://<site>/wp-admin/admin.php?page=jetpack&action=authorize&_wpnonce=<token>&redirect=<site>%2Fwp-admin%2Fadmin.php%3Fpage%3Djetpack&code=<code>&state=1
It worked normally with really no problem.
Although the problem isn't really in Jetpack nor in Wordpress, a huge amount of WordPress + JetPack users are on Hostgator. Should we do something about it (using my suggestion, base64 encoding or something else)? Would it require changes also on the Wordpress.com API (which is what I fear)?
Thanks for the report! We'll take a look at this!
Could you provide a site or two's URLs? If you'd like them to remain private, can you send a note via https://jetpack.com/contact-support/ and reply here once you've done so? On our Hostgator test accounts, I'm not hitting mod_security and want to be able to direct Hostgator's folks to an impacted site/server.
Additionally, if the mod_security block is recorded in the site's error logs, the specific block error would be helpful.
Thanks!
Hi! I've sent one site's URL on that page. Also, this page confirms that HG's _mod_security_ really blocks http:/ in the form data. But Jetpack activation worked normally when I removed the http:// part from the URL.
Thanks for the info ( 2645417-t ). HG nor I could duplicate and they reported that rule shouldn't impact the Jetpack process, but I don't believe any of us were looking at their Brazil variant.
I'll pass this onto the Hostgator team I'm working with.
HG was able to find the rule that impacted Jetpack connections in a specific set of circumstances. They are resolving this on their end, so I'm going to close this. Thanks for bringing this to our attention!
As of today, I can confirm that this happened to me. mod_security throws an 403 error if it finds http:// in the redirect variable.
I had the same problem, in the end I resolved it by creating or modifying .htaccess in the wordpress installation directory. The content of .htaccess I added disabled mod_security for the wordpress directory:
#
# Turn off mod_security filtering.
SecFilterEngine Off
# The below probably isn't needed, but better safe than sorry.
SecFilterScanPOST Off
Most helpful comment
HG was able to find the rule that impacted Jetpack connections in a specific set of circumstances. They are resolving this on their end, so I'm going to close this. Thanks for bringing this to our attention!