Closed (cannot reproduce)
Project:
Drupal core
Version:
6.1
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Anonymous (not verified)
Created:
10 Mar 2008 at 17:29 UTC
Updated:
21 Aug 2018 at 03:31 UTC
Jump to comment: Most recent
Comments
Comment #1
robloachMake sure your files directory is setup correctly? Moving it to Drupal 7 because if this is a bug in Drupal 6, it'll be a bug in Drupal 7 too. I haven't had this problem.
Comment #2
Anonymous (not verified) commentedThe admin/reports/status shows "File system" as "Writable (public download method)". Moving back to 6.1 since that is where I have the issue.
Comment #3
Anonymous (not verified) commentedOh, I should mention:
MySQL database 5.0.27
PHP 5.2.1
Web server Apache/2.2.0 (Fedora) DAV/2 PHP/5.2.1 SVN/1.4.3
Comment #4
robloachWhat theme are you using?
Comment #5
Anonymous (not verified) commentedThe default garland theme. I can give access upon request, it is a development system.
Comment #6
hilappa commentedI'm having the same problem. The sites/default/files directory is writable, drupal creates the optimized css file in the directory alright, but the .htaccess file prevents access to it.
Commenting the following lines in .htaccess solves the problem. Apparently this causes security issues?
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Comment #7
Anonymous (not verified) commented@hilappa, thanks for the info. I've alerted the security team to this issue. The associated node for the alert is http://drupal.org/node/66763.
Comment #8
gregglesYeah, uncommenting that line is definitely a "bad idea" in terms of security as that advisory mentions.
That said, I'm not sure what other solutions there are for your situation. I guess it is an apache configuration problem and you'll need to experiment with more apache options.
Comment #9
Anonymous (not verified) commentedFor me it is a mod-security issue. But what? :( Commenting the .htaccess had null effect for me.
Log Data
modsecurity_crs_50_outbound.conf
The above configuration is then only 403 statuses in my configuration files. Any help appreciated.
Comment #10
Anonymous (not verified) commentedBut adding
Allow from allhas success. Is this advisable?Comment #11
neural commentedSame issue here.
I have this on my HTML output page source :
<link type="text/css" rel="stylesheet" media="all" href="/sites/default/files/css/403c6ce98b830b5a3234d37c390e05a6.css" />shouldn't the path start with http://www.mysite.com instead of /sites on the rendered page?
I'm on Apache 2 / PHP 5 / Ubuntu-server.
Comment #12
Anonymous (not verified) commented@neural: I'm not understanding your question.
The .htaccess we've discussed has a path of sites/*/files/.htaccess and not the one at the document root. Each directory can have its own .htaccess file. Adding
Allow from allto sites/*/files/.htacess corrected the problem for me but there may be security risks I'm not aware of.Comment #13
neural commentedSorry I had forgotten to add the code tags, you can now read the comment again :).
I just notice that the url pointing to my aggregated/cached stylesheet isn't correct.
Comment #14
Anonymous (not verified) commentedThe optimize option creates one file from the many Drupal CSS (each module could have one or more plus the theme CSS) and compresses it. The file is created in sites/*/files/css so the file location is correct. No, it should not be located at the web document root. It would mean that your document root would need to be write accessible and that is a security risk. Even if you didn't use the optimize option the CSS are not located at the document root./sites is found in the document root. The server should know what to do.
Comment #15
dpearcefl commentedDoes this issue exist in current D6?
Comment #16
Anonymous (not verified) commentedI'll have to check it but give me a few weeks.
Comment #17
dpearcefl commentedComment #18
Anonymous (not verified) commentedI can't reproduce this now.