Home › Forums › BulletProof Security Free › BackUpWordPress 404 Not Found – wp-cron.php is returning a 403 Forbidden
This topic contains 17 replies, has 4 voices, and was last updated by
Austin 4 months, 2 weeks ago.
-
AuthorPosts
-
December 14, 2012 at 2:13 pm #707
Installed BackUpWordPress Version 2.1.3
Using Bulletproof Version .47.7
Got this message from BackUpWordpress:
BackUpWordPress has detected a problem.wp-cron.phpis returning a404 Not Foundresponse which could mean cron jobs aren’t getting fired properly. BackUpWordPress relies on wp-cron to run scheduled back ups
So, put bulletproof in default mode and the above message went away. What to do now?Thanks!
-
This topic was modified 2 weeks, 6 days ago by
AITpro Admin.
December 14, 2012 at 2:21 pm #708Go to the BPS Edit/Upload/Download page and click on the “Your Current Root htaccess File” tab and scroll down in your root .htaccess file until you see this code below and remove HEAD from the Request Methods in this filter.
# REQUEST METHODS FILTERED # This filter is for blocking junk bots and spam bots from making a HEAD request, but may also block some # HEAD request from bots that you want to allow in certains cases. This is not a security filter and is just # a nuisance filter. This filter will not block any important bots like the google bot. If you want to allow # all bots to make a HEAD request then remove HEAD from the Request Method filter. # The TRACE, DELETE, TRACK and DEBUG request methods should never be allowed against your website. RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC] RewriteRule ^(.*)$ - [F,L]December 14, 2012 at 2:47 pm #709Yes, I see. That is the same fix for the 403 and 302 error listed on your page at
http://www.ait-pro.com/aitpro-blog/2252/bulletproof-security-plugin-support/checking-plugin-compatibility-with-bps-plugin-testing-to-do-list/
The message is gone so I am going to assume this worked. Will know more tomorrow when I check to see if the scheduled backup did indeed, backup.
Thanks!
December 14, 2012 at 3:09 pm #710Yep we use this great backup plugin ourselves so the fix definitely works. ;) I was not aware that a 404 Not Found error also occurs so i will add that information to the fix as well. Thanks.
January 1, 2013 at 12:35 pm #879I have the same problem as hhart. I am using the same exact plugin for programmed backups. I receive the same message:
wp-cron.phpis returning a404 Not Foundresponse which could mean cron jobs aren’t getting fired properly. BackUpWordPress relies on wp-cron to run scheduled back ups. I have contacted my webhost. They say that my wp-cron.php might be corrupted and that I should replace it on the server with a new uploaded one. They also proposed a web page to read but honestly, I have difficulty making heads or tails with all this information. You (the Key Master of this forum) suggests to remove the ‘HEAD’ from some section but I am not even sure what to do exactly.
Thanks
P.S.: This is the page the webhost suggests: http://wolfiezero.com/519/wp-cron-giving-you-the-404s/-
This reply was modified 4 months, 3 weeks ago by
char.
January 1, 2013 at 12:58 pm #881Do you have the BPS plugin installed?
If so, then do these steps to remove the HEAD Request method from the BPS security filter/code in your root .htaccess file.
Go to the BPS Edit/Upload/Download page and click on the “Your Current Root htaccess File” tab and scroll down in your root .htaccess file until you see this code below and remove/delete HEAD from the Request Methods in this filter as shown below.
# REQUEST METHODS FILTERED # This filter is for blocking junk bots and spam bots from making a HEAD request, but may also block some # HEAD request from bots that you want to allow in certains cases. This is not a security filter and is just # a nuisance filter. This filter will not block any important bots like the google bot. If you want to allow # all bots to make a HEAD request then remove HEAD from the Request Method filter. # The TRACE, DELETE, TRACK and DEBUG request methods should never be allowed against your website. RewriteEngine On RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK|DEBUG) [NC] RewriteRule ^(.*)$ - [F,L]January 1, 2013 at 2:41 pm #882Thanks for replying. Yes I have BPS installed.
If I understand correctly, just to make it clear, all I have to do is to delete the term ‘HEAD’ in this section?:
{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK|DEBUG) [NC]Also, I have another problem. I have made a few changes since a couple of months and suddenly my WP readme.html file is nolonger htaccess protected. Do you have any idea why it could be like that?Thank you.January 1, 2013 at 2:47 pm #883yes, that is correct.
How do you know your WP readme.html file is not protected? Is BPS telling you it is not protected? Are you seeing error messages? What changes did you make? Does the very top line of the root .htaccess have this - # BULLETPROOF .47.7 >>>>>>> SECURE .HTACCESS – or is there something above this line or have you modified this line?
January 2, 2013 at 5:40 pm #890I know it because BPS says it is not, in the ‘Additional Website Security Measures’ section, in read. I am not seeing any error messages besides this one. I have made a few changes in the ‘PHP Server / PHP.ini Info’ section. A few configurations were in red, such as ‘Expose PHP’, ‘Allow Persistent connections’, ‘Magic Quotes’, ‘Display Errors’ and ‘Allow URL fopen’, if I remember correctly. I asked my webhost to correct them. And the problem appeared just after that, coincidence or not. And for the very top line of the root.htaccess, there is another line, that seems to have been added, beginning with ’SuPHP_ConfigPath /home/ (then my username) /public_html/
Could it be a line added by the technician to make the modifications that is causing this? Should I delete it? Should I cancel the changes that I asked for, even if they appear in red?
Many thanks.January 2, 2013 at 6:23 pm #891Yep the php/php.ini handler added to the top line of the .htaccess file is the problem. Cut and paste it under this section of your root .htaccess file and everything will be fine.
# ADD A PHP HANDLER
# If you are using a PHP Handler add your web hosts PHP Handler below
SuPHP_ConfigPath /home/ (then my username) /public_html/January 3, 2013 at 8:17 am #892It worked. Everything looks fine, the alarm went off. Returning to my first issue, I have a question. Is deleting the ‘HEAD’ command in the ‘Request Methods Filtered’ not risking of endangering the safety of the installation? Could it make more unstable or more vulnerable?
Many thanks.January 3, 2013 at 8:26 am #893The HEAD Request filter is just a nuisance filter to block spambots and junkbots and is not a security filter. It does not have anything to do with security so removing it does not make your site any less safe.
# REQUEST METHODS FILTERED # This filter is for blocking junk bots and spam bots from making a HEAD request, but may also block some # HEAD request from bots that you want to allow in certains cases. This is not a security filter and is just # a nuisance filter. This filter will not block any important bots like the google bot. If you want to allow # all bots to make a HEAD request then remove HEAD from the Request Method filter. # The TRACE, DELETE, TRACK and DEBUG request methods should never be allowed against your website.
January 3, 2013 at 8:58 am #894Something else has come up. Somehow, after I made the modification and that the alarm went off, I had to put the BulletProof Mode back on. The problem is, the modifications that I asked my webhost to do are gone now. The php.ini file still exists, the commands are at ‘off’ as they are supposed to be but now they are ‘on’ in BPS. I re-pasted the sequence SuPHP_ConfigPath /home/ (then my username) /public_html/ in the # ADD A PHP HANDLER section but it is not working. The route seems to be cut. By the way, am I too zealous by wanting these changes? If they are not that critical, maybe I could just forget about them.
Thanks for your patience.January 3, 2013 at 9:32 am #895If you add your php/php.ini handler to the BPS CUSTOM CODE TOP: Add php.ini handler code and / or miscellaneous custom code here text box and save your changes and then click the AutoMagic buttons and Activate Root folder BulletProof Mode 2 things will happen. Your php/php.ini handler is saved permanently. Every time you click the AutoMagic buttons and Activate Root folder BulletProof Mode you php/php.ini handler will be added to your root .htaccess file.
Custom Code Help Resources:
The Blue Read Me help button on the Custom Code page.
January 3, 2013 at 10:22 am #896I will probably be allright at this point (I hope). Thank you. You have been very helpful. Obviously, you know your stuff. Keep going.
January 7, 2013 at 1:17 am #902Thanks for this thread – saved me a bundle of time figuring out what was wrong with the backup plugin.
Question though, does the HEAD Request filter need to be removed for any plugin that uses wp-cron.php?
Thanks.
Austin.January 7, 2013 at 7:15 am #904Not necessarily and not usually. Typically the problem that can occur with Crons, such as scheduled backup crons is that the wget command is being used instead of the lynx command. BPS blocks the wget command. So you can either remove the wget command from BPS security filters or use lynx -source instead of wget -O. http://forum.ait-pro.com/forums/topic/wget-gives-403-error-when-bps-is-active/
January 9, 2013 at 11:38 pm #959Thanks – posted over at WP on the plugin thread.
-
This topic was modified 2 weeks, 6 days ago by
-
AuthorPosts
You must be logged in to reply to this topic.
