
mindlessconsumer at gmail
Nov 23, 2009, 11:32 PM
Post #5 of 6
(572 views)
Permalink
|
|
Re: Ticket attachments fail even when max_size set to -1
[In reply to]
|
|
On Nov 20, 2:17 am, "RAAFET DORMOK" <raafet.dor...@biat.com.tn> wrote: > Make that: > > [attachment] > max_size = 500000 > render_unsafe_content = false The render_unsafe_content didn't actually help with mod_security. The only way to bypass was this: In my modsecurity.conf, I added an id value to the following rule: # Did we see anything that might be a boundary? #SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \ "phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'" So it looks like this now: # give this rule an id, so we can make an exception SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \ "phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.',id:111" In my website virtual host file: <IfModule mod_security2.c> # bigger uploads SecRequestBodyLimit 10240000 # see line 64 of modsecurity.conf SecRuleRemoveById 111 </IfModule> This allowed me to disable the checking for an unmatched boundary just for my trac virtual host, and not the others. It does seem that this shouldn't have to be done, and that multipart uploads/attachments in trac should be sent in such a way that they don't have an unmatched boundary. IE, I am running several other full-featured web apps on my other virtual hosts (drupal, wordpress etc), and have never had to modify my default mod_security rules to make them work. Is there something I'm missing, or should I file a bug/enhancement? -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users [at] googlegroups To unsubscribe from this group, send email to trac-users+unsubscribe [at] googlegroups For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
|