[Apache] mod_rewrite naar non-www map

[RickyHeijnen]

Helleuw,

Wegens ontwerpbeslissingen die gemaakt zijn, staan alle css bestanden in een map die niet web-accessible is. Deze worden vervolgens door een klein PHP script wel toegankelijk gemaakt:

404.php

code:

if(substr($_GET['css'], 0, 4) == "css/"){
   header("Cache-Control: private");            
   header("Content-type: text/css");      

   readfile("/var/www/myproject/". $_GET['css'] ."");
   die();
}

http://www.myproject.org/css/style.css -> gaat naar 404.php en die geeft het .css bestand terug


Nu vroeg ik me af of dit ook kan dmv een apache mod_rewrite. Nu heb ik dit al geprobeerd, maar dat lijkt niet te werken:

code:

RewriteRule ^css/(.*)$ /var/www/myproject/css/$1

Ik zit op een shared hosting en ik had gevraagd of ze die 2 mappen voor mij konden symlinken, maar dat was blijkbaar niet mogelijk.

Dusssssss... wie kan mij helpen....


Note: /var/www/myproject/ is niet web-accessible, dat lijkt misschien wel zo.

[4VAlien]

En het grote probleem met het verplaatsen van de css in de huidige situatie is? Het is niet zo dat je de css kan verbergen oid. Het lijkt me ook krom dat je zomaar buiten de www tree documenten zou mogen opvragen met een http request dat door Apache verwerkt wordt.

[RaZ]

Waarom mik je eerst je CSS-bestanden op een plek waar de webserver er niet bij kan, om vervolgens een rule te maken naar plek waar de webserver niet mag komen?

Nu weet ik niet wat de anderliggende gedachte is om de CSS-bestanden buiten de webserver te zetten, en het dan door php wel te laten versturen.

Deze constructie geeft enkel overhead die niet nodig is. Het zal niet dramatisch veel zijn natuurlijk, maar efficient is het niet. Wat is de reden voor die constructie?

[Gomez12]

RaZ schreef op zaterdag 26 juli 2008 @ 01:06:
Waarom mik je eerst je CSS-bestanden op een plek waar de webserver er niet bij kan, om vervolgens een rule te maken naar plek waar de webserver niet mag komen?

Nu weet ik niet wat de anderliggende gedachte is om de CSS-bestanden buiten de webserver te zetten, en het dan door php wel te laten versturen.

Deze constructie geeft enkel overhead die niet nodig is. Het zal niet dramatisch veel zijn natuurlijk, maar efficient is het niet. Wat is de reden voor die constructie?

Buiten de webserver heb ik geen idee van, maar via php laten versturen kan ik juist wel begrijpen.
Cache-headers zetten, on the fly minifyen terwijl je source wel goed leesbaar blijft, meerder css-bestanden samenvoegen naar 1 bestand.

De overhead is praktisch weg te werken door expires headers mee te zenden en de boel goed te cachen.

Voor de client is het heel erg efficient, voor de developer ook want hij heeft nog steeds de beschikking over alle sources inclusief commentaar etc.

Alleen dat buiten de webroot zetten dat vind ik overbodig, het liefste wil ik voor debugging doeleinden ook kunnen terugschakelen naar de standaard css. En het is ook niet alsof de css bedrijfsgeheimen bevat ofzo.

[RickyHeijnen]

De situatie is zo dat er 1 map is met CSS bestanden en 1 map met images is (allebei niet-webaccessible, zodat ze soort van generieke status hebben) waar vervolgens 15 grote sites gebruik van maken. Deze oplossing is zo bedacht zodat met 1 upload alle 15 sites meteen aangepast zijn.

Misschien dat dat het verhaal iets helderder maakt.

code:

/var
   /www
      /css 
      /inc => php core files
      /images
      /web
         /project1 => web accessible, klant kan hier op FTP inloggen met eigen gegevens
         /project2 => idem
         /project3 => idem
         /project4 => idem

[ Voor 0% gewijzigd door RickyHeijnen op 26-07-2008 01:21 . Reden: taalfout ]

[krvabo]

zoetericky schreef op zaterdag 26 juli 2008 @ 00:53:

PHP:

   readfile("/var/www/myproject/". $_GET['css'] ."");

[Verwijderd]

Wat gebeurt er als ik in $_GET['css'] bijvoorbeeld '../../../../../../../../../../../etc/passwd' stop?
Juist ja... Even een betere oplossing bedenken voor dit gapende securityhole

Bijvoorbeeld strstr($_GET['css'], '/mapwaarjecssfileststaan') validaten.

[ Voor 17% gewijzigd door Verwijderd op 26-07-2008 01:39 ]

[Gomez12]

Simpel advies, ga eens goed nadenken over wat je wilt hebben en hoe je dit wilt hebben.

Als ik nu lees dat je 15 grote sites bedient vanaf een shared hosting accountje waarop je niet alles kan aanpassen, je blijkbaar een 404-error misbruikt om toch maar data te genereren en je nog een leuke security risk erin hebt zitten...

Dan ga ik denken wat jij grote sites noemt...

@magicaltrevor : in $_GET['css'] kan geen '../../../../../../../etc/passwd' zitten als de readfile uitgelezen wordt. Dat wordt geblokkeerd door regel 1, je kan natuurlijk wel 'css/../../../../../../../../etc/passwd' doen dan werkt het opeens wel...

[RobIII]

Mja, dit gaat (buiten de vage, vage constructie met PHP), dus niet over programmeren en dus: Waar hoort mijn topic?
PRG >> WSS

[RickyHeijnen]

Het PHP script is veel uitgebreider, ik heb hier alleen de belangrijkste regels neer gezet.

Ik wil alleen weten of dit ook met mod_rewrite op te lossen is. Maar nu ik er zelf over nadenk lijkt het me dat ik met zo'n PHP script de beveiliging veel beter kan controleren dan met een regeltje in me htacces.

En misschien kan ik dan beter dit doen ipv die 404 constructie:

code:

RewriteRule ^css/(.*)$ get_css.php?file=$1