Hi,
I cannot reproduce the error.
Can you check your HTTP logs (access and error logs) and paste here the corresponding lines that triggered the 404 error?
HTTP log doesn’t contqin anything…
Its only saying in the WP Backend “HTTP Error”.
BUT, I do have in the Ninja Firewall following entries:
[1461568339] [0.00219] [lrc.mydomain.ch] [#2970311] [0] [3] [213.158.139.50] [403] [POST] [/wp-admin/async-upload.php] [Blocked file upload attempt] [test.png, 76,497 bytes]
I can give you backend access and ftp access to one of the multisites if you want. stefan.wuk.ch is my adress.
When I login I can see under Firewall on Networksetting:
http://www.mydomain.ch/wp-admin/network/admin.php?page=NinjaFirewall
Stefan (you are whitelisted by the firewall)
I change to the other subpage:
http://lrc.mydomain.ch/wp-admin/upload.php
try uploading image:
test.png HTTP-Fehler.
So: I’m correctly recorgnized as admin but cannot pload images. Is it because the network installation is on www. and the subpage on lrc. subdomain?
Perhaps the cookie on the subdomain not set which recorgnize me as admin? As I do not use the non-www for the networksetup?
It looks similar to this discussion: https://wordpress.org/support/topic/the-firewall-is-blocking-all-downloads-of-all-administrators?replies=12
It seems it could be a PHP session issue between the domain and subdomain but I am unsure as I cannot reproduce the problem. Most multisite users don’t have that problem either.
Do you have a caching plugin that could mess with your PHP session?
In the meantime, you could try to whitelist “/wp-admin/async-upload.php” if you want, with the .htninja script:
<?php
/*
+===================================================================+
| NinjaFirewall optional configuration file |
| |
| See: http://nintechnet.com/ninjafirewall/wp-edition/help/?htninja |
+===================================================================+
*/
if (strpos($_SERVER['SCRIPT_FILENAME'], '/wp-admin/async-upload.php') !== FALSE) {
return 'ALLOW';
}
Caching in the backend? no, nothing.
PHP session cannot be messed up, otherwise wordpress backend would not work correctly?!? and your lugin says correctly recorgnized as admin.
Do you want to have access to the site?
Can grant you access including ftp for debuggin if you want.
write me a mail to stefan[a]wuk.ch
But yes, it seams its the same issue as the other people have. I still think the issue is cased by wrong definition of the Cookiedomain “nfw_goodguy” in the plugin. I will check where this is set.
small change in the code and then its working for me:
ninjafirewall.php:
if (! headers_sent() ) {
if (version_compare(PHP_VERSION, '5.4', '<') ) {
if (! session_id() ) {
ini_set('session.cookie_domain', substr($_SERVER['SERVER_NAME'],strpos($_SERVER['SERVER_NAME'],"."),100));
session_start();
$_SESSION['nfw_st'] = 1;
}
} else {
if (session_status() !== PHP_SESSION_ACTIVE) {
ini_set('session.cookie_domain', substr($_SERVER['SERVER_NAME'],strpos($_SERVER['SERVER_NAME'],"."),100));
session_start();
$_SESSION['nfw_st'] = 2;
}
}
}
Please see the ini_set line which change the Cookie Domain to the root domain without www in the beginnning.
Its what I suspected, If you use www. to login in MU site, then this is the issue that all subpages are not working. Set the correct domain and everything is fine.
Could you make that fix?
PHP session cannot be messed up, otherwise wordpress backend would not work correctly?!?
WordPress uses cookies, NinjaFirewall uses PHP session. That’s two different things.
Please see the ini_set line which change the Cookie Domain to the root domain without www in the beginnning.
This could be an important security risk: you will allow any whitelisted users to remain whitelisted throughout the network (domain + all subdomains).
You need at least to make sure this applies only to the Superadmin, and strictly no one else (admin, users).
But we cannot add code such as “if ( current_user_can('manage_network') )” inside the code that checks the session, because it would trigger an error.
I will check later, but I assume the whole code should be moved to a function and called from the ‘admin_init’ hook.
I found out the issue. It was a bit tricky because that issue affects only the free WP Edition, not the premium WP+ Edition and all my latest tests were done with the premium one.
I will fix that in the next release.
Note that your solution may work for you, but in many cases it won’t. For instance, $_SERVER[‘SERVER_NAME’] may not always be the domain name (it could be another domain sharing the same IP, or even the server IP). There is also the security risk I mentioned.
when its fixed in tghe next release, then its fine. thx
