I have been look around trying to get this working right for a while now, and finally bit the bullet and posted here.
I've got a LAMP stack with ModSecurity using the OWASP core rule set (v 2.2.5) and just installed Wordpress. I expected conflicts with ModSecurity, but I haven't been able to ignore or work aroudn the only error I've encountered so far.
The Apache error.log file and the modsec_audit.log both list the same error:
ModSecurity: Rule 7f5d9a449228 [id "950901"][file "/etc/modsecurity/owasp-crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"][line "77"] - Execution error - PCRE limits exceeded (-8): (null).`
I've tried creating a new .conf file where the crs conf files are located containing
<LocationMatch .*>
<IfModule mod_security2.c>
SecRuleRemoveById 950901
</IfModule>
</LocationMatch>
and even removed the IfModule statement and then LocationMatch statement when it didn't work.
Finally I resorted to commenting out lines 76 and 77 in the .conf file, and the error still appeared. This also had no effect.
Only changing SecRuleEngine to Off in modsecurity.conf finally let me access the page. Of course this defeats the purpose of ModSec.
Where am I going wrong?
Try adding this to your php.ini file (or included conf file):
pcre.backtrack_limit = 10000000
pcre.recursion_limit = 10000000
And then this to your modsecurity.conf:
SecPcreMatchLimit 150000
SecPcreMatchLimitRecursion 150000
This should allow for recursion without having to fully disable mod_security.
Related
I'm trying to add a MP4 video to my media library. It doesn't give any error but when I try to play the video it gives this message inside the video player:
Media error: Format(s) not supported or source(s) not found
The video size is 2MB.
There seems to be a bug in WordPress Core about this:
https://core.trac.wordpress.org/ticket/42874#comment:8
An issue is also opened in the mediaelement GH repo:
https://github.com/mediaelement/mediaelement/issues/2390
The actual problem comes from Safari:
IMPORTANT NOTE for Safari users (Jun 8, 2017)
Since Sierra version, autoplay policies have changed. You may experience an error if you try to execute play programatically or via autoplay attribute with MediaElement, unless muted attribute is specified.
I've also bumped into this issue, but can only reproduce it in Safari, it works on Chrome and Firefox.
Hope this helps!
Make sure the filename has no spaces, apostrophes, slashes or other non-alphanumeric characters (such as $, % and &). Rename the file before uploading if it does. To preserve readability, it's work for me
Check if there is a .htaccess file in the <wp-root>/wp-content folder of your wordpress installation, this file determines which file the webserver is allowed to make available for download. (You will need access to the server for this, you cannot do this from WordPress itself, I think.)
In my case, this file looked as follows:
# Disable access to all file types except the following
Order deny,allow
Deny from all
<Files ~ ".(xml|css|js|jpe?g|png|gif|pdf|docx|rtf|odf|zip|rar)$">
Allow from all
</Files>
Which means: only allow downloading files with the listed extentions. Any other file (such as mp4) would result in a 403 - Forbidden error.
Fix the problem by adding the mp4 to the list of allowed files:
...
<Files ~ ".(xml|css|js|jpe?g|png|gif|pdf|docx|rtf|odf|zip|rar|mp4)$">
...
After spending several hours trying to find a solution i finally have!
I managed to fix the issue by just changing the file name of the MP4. I had the file name as "video_300x250.mp4". by changing it o simply "video_01.mp4" it fixed the issue for me.
I literally spent so long trying to re-install wordpress, mess about with SSL and plenty of other stuff. Trying to google it no one has found any answer. It might be the fact that there are numbers with the letter "x" in it, or some other combination of letters which doesn't work.
I hope this helps for anyone searching for this.
The easiest solution I came up with is to change the video's format to webm from mp4 that will solve the issue.
Upload your video to YouTube then download it and upload the YouTube download to Wordpress and it works.
I tried a lot for this problem.
But I did not get the result.
and one way fix error is to
delete this code
<Files ".user.ini">
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
</Files>
and
The problem was solved
So i'm working with the wpmudev snapshot plugin which gives an 'max_execution_time' warning (30 is to low), when I update this to 180 by adding
php_value max_execution_time 180
to the .htaccess file (wp root) my site gives an internal server error. Is there an reason why this happens? And how can I fix this?
your code is correct and refer below scenario,
Check with your error log and if it is a PHP error try to troubleshoot that.
what is your server engine, because Apache engine only have .htaccess file others like nginx not support .htaccess file
If not got solution check with your hosting before that make sure your site not have an issue.
I have an rewrite recursion error somewhere on my website that Google Bot caused, but I can't find the url that caused it because my Loglevel is low. I raised it but it has not happened again so far.
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
All Rewriterules look fine to me and have the [L] flag, except this one.
I can't quite understand it. It is from the open source shop system Magento.
As far as I can tell it does nothing but sets the environment variable E. But isn't that a very stupid way of doing that? Shouldn't you use SetEnv if that was the goal?
Symfony developers Group has a good answer for it. I quote:
it looks like your hosting is running php as a fcgi, not a php5_module, like your localhost does. ( phpinfo - Server API: CGI/FastCGI )
the point is that php5_module automatically handles HTTP_AUTHORIZATION headers, but fcgi_module does not.
solution is simple - add this line to your .htacces on your hosting server:
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
It worked for me
This line is setting the environment variable to the value of user authentication string - essentially setting a variable rather than constant value. As far as I know, SetEnv and SetEnvIf only allow you to set an environment variable to a predetermined constant.
The variable being set is actually HTTP_AUTHORIZATION, not E. I would guess this is part of the user authentication process.
Most htaccess 404 error rules are based on an absolute directory location, eg /404.php. I want one that is relative to the location it's placed in (so when I transfer from test environment in WAMP to live, I don't have to hope I edit the file right).
Unfortunately,
ErrorDocument 404 404Error.php
Just prints out 404Error.php to the browser, it doesn't call the actual error page like
ErrorDocument 404 /FOOBAR/404Error.php
does.
Edit:
I guess I wasn't clear enough. Test environment is a WAMP local server, with the error file at /FOOBAR/404Error.php while the 'live' server would be www.fubar.com/404error.php -- placing it in the root.
How's this?
ErrorDocument 404 ../directory/404page.html
RewriteBase /FOOBAR/
ErrorDocument 404 404Error.php
This works too, but Tycho's solution is a bit more elegant. Only use this one if you don't plan on using .htaccess for anything outside of /FOOBAR/ pretty much.
I've troubles with Drupal 6 and (maybe) mod_rewrite:
if I go to http://127.0.0.1/drupal/node/115/edit?destination=admin%2Fcontent%2Fnode and then I save the node, I don't get redirected to admin/content/node, but it directs me to node/115 :-(
Why??
In my .htaccess I uncommented: RewriteBase /drupal (because my drupal path is /var/www/htdocs/drupal)
My server is running Apache 2.2.4 on Slackware 12
Any help I'll be appreciated :D
It does look like a configuration problem, because this normally works. You can debug it by adding some dsm() dumps in includes/common.inc/drupal_goto() : this is where the destination parameter is processed.
Note that if some module traps your form submission, for instance by declaring a _validate or _submit handler, it can very well change the redirection information: check whether you can reproduce this without contrib modules enabled.