RewriteRule to non-accessible directory

[eokken]

Mijn huidige directory structuur ziet er zo uit:

public_html/
public/
templates/

In mijn htaccess bestand controleer ik of de opgevraagde url bestaat in de map public/
Voorbeeld: site.nl/images/image.jpeg, kijken in public_html/public_images/ naar image.jpeg

Nu wil ik die public/ map niet meer in de public_html hebben, voor een speciale reden. Ik heb geprobeerd met ../ te werken maar Apache kan daar niet bij.

Ik heb ook geprobeerd alle requests naar een php bestand te sturen. Maar dan moet ik afhankelijk van de extensie, de mime type bepalen en de juiste header terugsturen. Dat lijkt me niet echt generiek. (Of mis ik een magische functie? )

Nu vroeg ik mij af of iemand hier iets voor weet.

Erwin.

[ Voor 57% gewijzigd door eokken op 13-09-2012 13:51 . Reden: Hopelijk is het nu duidelijker. ]

[YopY]

Wat probeer je precies te bereiken? Een rewrite naar een niet-bereikbare locatie gaat namelijk gewoon niet werken.

[jeepey]

Ik heb je post 3x gelezen maar snap nog steeds niet zo goed wat je nu precies wilt. Misschien kun je proberen het iets duidelijker te verwoorden?

[MueR]

Wat voor files hebben we het uberhaupt over? PHP files is het niet voor nodig namelijk, die kunnen gewoon vanuit je entry point worden aangeroepen, ook al staan ze buiten je publieke directories. Voor JS/CSS/afbeeldingen is het eigenlijk gewoon nutteloos om ze buiten de public_html te zetten. Je gaat ze toch over de lijn sturen, dus wat is daar het voordeel?

[Verwijderd]

Probeer je bestanden af te schermen? Dit kun je vrij eenvoudig doen met een deny from all en de bestanden te serveren met php.

Maar zoals je wel merkt is je verhaal niet duidelijk genoeg

[eokken]

Ik heb het verhaal een beetje aangepast. De reden is dat ik framework heb met een v0, v1, v2 en dergelijke. Daar staanallemaal php bestanden maar ook de html, css en javascript bestanden. En die code staat allemaal buiten de public_html, om precies te zijn in dezelfde map als alle domeinnamen:

domein.nl/
domein2.nl/
framework/

[Kalentum]

Ik denk dat je op zoek bent naar Alias.

[jeepey]

Het lijkt mij om te beginnen een 'bad practice' om js en css files in een framework op te nemen. Die horen thuis in de presentatie-laag van je webapp.

Maar volgens mij is er ook geen fatsoenlijke oplossing voor hetgeen je probeert te bereiken. In theorie zou je inderdaad een php file de bestanden kunnen laten ophalen van disk en deze met de juist filetype header weer laten retourneren aan de webclient. Dat is echter een bijzonder omslachtige manier en tevens niet handig voor de performance van je code.

[eokken]

Het probleem is dat mijn webapp meerdere versies heeft, die allemaal online staan zodat ik kan switchen tussen versies wanneer ik wil. De publieke items moeten wel in een publieke root en het framework wil ik niet in een publieke root. Dus dan krijg ik twee keer de mappen: v1, v2, v3, etc.

[Keeper]

Je zou kunnen kijken hoe andere frameworks dit oplossen, bijvoorbeeld in CakePHP (versimpelde weergave):

app/
  webroot/
lib/

In lib/ zit dan de core van het framework en in app/ je eigen applicatie in dat framework (Models, Controllers, etc). app/webroot is je "public" folder met daarin gewoon je css/js mappen en een index.php die al je requests naar de juiste controllers etc doorstuurt.

Alleen wat er in app/webroot zit is dan dus world-readable, de rest niet.

[MueR]

Op het moment dat je CSS en images in je framework zit, heb je iets gewoon niet goed gedaan. Dat soort spul hoort niet in een framework te zitten, maar in een losse directory die gewoon wel in een public folder kan staan.

[Kalentum]

TS zegt 'framework' maar bedoelt misschien: een CMS wat door meer klanten gebruikt wordt. Gedeelde functionaliteit dus. En daar kunnen ook statische elementen (javascript, css, images) bijhoren. BV een nieuwsmodule waar hij altijd een kalendertje voor wil hebben.

In dat geval vind ik het niet echt raar of vies als bepaalde gedeelde elementen slechts 1x voor al die klanten worden opgeslagen. bv een plaatje /srv/framework/v1/public/img/delete.png dat zowel via www.klantx.nl/common/img/delete.png als via www.klanty.nl/common/img/delete.png bereikt kan worden.

Daarom denk ik dat hij Alias nodig heeft:

Alias /common /srv/framework/v1/public/

Kun je altijd nog klantspecifiek zijn door in /srv/sites/klantz.nl/public/img/ een andere delete.png te zetten en die in templates te gebruiken.

[eokken]

@rutgerw Dit is inderdaad bijna de situatie die ik heb. Ik zei framework om het even globaal te houden. Ik had niet verwacht dat er zoveel offtopic zou gaan. Ik ga dat Alias proberen en dan laat ik het weten.

update: Ik krijg hierbij een "500 Internal Server Error". Ik vraag me af of je wel een Alias kan maken buiten de public_html, die van jou zit daar nu duidelijk voor.

Ik krijg in mijn Apache logs: Alias not allowed here.
En toen probeerde ik AliasMatch: AliasMatch not allowed here.

[ Voor 41% gewijzigd door eokken op 13-09-2012 18:28 ]

[MueR]

Tja, voor dergelijke dingen kan je wel met aliassen werken, maar dan zal die directory waar je naar aliassed wel publiek toegankelijk moeten zijn en opgenomen in je httpd.conf.

[eokken]

Dat is beide niet het geval volgens mij. Hij staat buiten de public_html en volgens mij heb ik geen toegang tot de httpd.conf. Iemand anders nog ideeën? Een publieke map 0.1, 0.2, 0.3, etc is lelijk en mijn hele "framework" in de public_html zetten lijkt me ook niet echt iets.

[Kalentum]

eokken schreef op donderdag 13 september 2012 @ 13:20:
Ik heb ook geprobeerd alle requests naar een php bestand te sturen. Maar dan moet ik afhankelijk van de extensie, de mime type bepalen en de juiste header terugsturen. Dat lijkt me niet echt generiek. (Of mis ik een magische functie? )

Dat kan ook nog: http://www.php.net/manual/en/function.finfo-file.php

[Gomez12]

eokken schreef op donderdag 13 september 2012 @ 19:19:
Dat is beide niet het geval volgens mij. Hij staat buiten de public_html en volgens mij heb ik geen toegang tot de httpd.conf. Iemand anders nog ideeën? Een publieke map 0.1, 0.2, 0.3, etc is lelijk en mijn hele "framework" in de public_html zetten lijkt me ook niet echt iets.

Simpel gezegd : Alles wat je rechtstreeks (zonder tussenlaag als bijv php) vanuit apache wilt serveren (js/css/plaatjes etc.) moet beschikbaar zijn in een ingestelde publieke directory in httpd.conf.

Kan je je httpd.conf niet aanpassen dan moet je dus of :
- het geheel in je public root zetten
- het geheel gaan proxy'en op localhost via php oid. (en hier ga je niet vrolijk van worden)

Maar wat is er mis om in je klanten-directory 1 nieuwe "klant" aan te maken : Framework? Dan heb je qua afscheiding net zo veel afscheiding als tussen je andere klanten en in principe (mits goed ingericht) moet dat vanuit klant-perspectief hetzelfde zijn als buiten public root plaatsen, enkel heb je nu wel gewoon het publiekelijk toegankelijk voor gebruik etc.

[Gomez12]

rutgerw schreef op donderdag 13 september 2012 @ 20:21:
[...]


Dat kan ook nog: http://www.php.net/manual/en/function.finfo-file.php

Het probleem met dit soort functies is dat ze naar verhouding redelijk zwaar zijn tov de functies van apache.

Bij 1 bestandje ga je dit niet merken, maar ga je 20 images zo oppakken per pageview dan gaat het toch wel redelijk zwaar worden.

[eokken]

@Gomez12 Ik snap je laatste alinea niet helemaal. Dat PHP verhaal kan je vergeten, dat is inderdaad superlelijk. Ik denk dat ik zo'n directory structuur ga gebruiken:

domains/
mijncmsdomein.nl/public_html/public/0.3/images/header.png
klantwebsite.nl/public_html/public/images/header.png
framework/0.3/..

[Gomez12]

eokken schreef op donderdag 13 september 2012 @ 20:45:
@Gomez12 Ik snap je laatste alinea niet helemaal. Dat PHP verhaal kan je vergeten, dat is inderdaad superlelijk. Ik denk dat ik zo'n directory structuur ga gebruiken:

domains/
mijncmsdomein.nl/public_html/public/0.3/images/header.png
klantwebsite.nl/public_html/public/images/header.png
framework/0.3/..

Die opzet bedoel ik dus juist (even aangenomen dat framework dan geen js/css/images etc meer bevat)

[Grijze Vos]

je zou ook kunnen symlinken, als je geen Apache instellingen wilt wijzigen.

[Gomez12]

Grijze Vos schreef op donderdag 13 september 2012 @ 23:55:
je zou ook kunnen symlinken, als je geen Apache instellingen wilt wijzigen.

Hmmm, geen toegang tot httpd.conf, ik vermoed dat hij dan geen shell-account heeft, maar enkel ftp-toegang.

En gaan symlinken vanuit een php-script alhoewel het technisch mogelijk is zou ik toch eerder naar een andere host overstappen dan dit soort "rare" trucs toe te passen.

[MueR]

Ook daar ga je niet veel mee bereiken. Ik zou mijn framework zo schrijven dat het geen gekke symlink constructies nodig heeft. Versioning is leuk in je framework, mits je over een eigen server beschikt, want dan kan je het goed doen. Je zal echter altijd rekening moeten houden met een situatie waar een klant niet gebruik wil maken van jouw hostingoplossing.

[ Voor 48% gewijzigd door MueR op 14-09-2012 01:08 ]

[Gomez12]

MueR schreef op vrijdag 14 september 2012 @ 01:08:
Je zal echter altijd rekening moeten houden met een situatie waar een klant niet gebruik wil maken van jouw hostingoplossing.

Dat is in principe geen probleem zolang je versioning maar klopt. De klant zal altijd maar 1 versie hebben draaien (en meerdere klanten op een server die je niet zelf beheert vind ik niet mijn probleem).

Op je eigen server kan je simpelweg vhosts met versioning templates gaan gebruiken.
Doe ik tenminste, gewoon per major versie maak ik een vhost-template aan en mensen kunnen daaruit kiezen zodat mensen zelf altijd kunnen verwijzen naar /assets/static/images/ en afhankelijk van de versie gaat die dan een dir en zolang ik maar een zip-file aanbied met een pad /assets/static/images/ dan kan iedereen de zip-file uitpakken en de boel op eigen server draaien.
"Mijn klanten" die kunnen simpelweg door een andere vhost-template te kiezen overschakelen naar een nieuwe versie

[eokken]

Naar mijn mening kan je best versioning gebruiken op een shared hosting. Het is niet zo ideaal als wanneer je over je eigen server beschikt maar ik zou zo geen reden kunnen verzinnen waarom dat een probleem voor de klant zou moeten zijn.

[Grijze Vos]

MueR schreef op vrijdag 14 september 2012 @ 01:08:
Ook daar ga je niet veel mee bereiken. Ik zou mijn framework zo schrijven dat het geen gekke symlink constructies nodig heeft. Versioning is leuk in je framework, mits je over een eigen server beschikt, want dan kan je het goed doen. Je zal echter altijd rekening moeten houden met een situatie waar een klant niet gebruik wil maken van jouw hostingoplossing.

Symlinken is zo oud als de weg naar Rome. Is niks geks aan. Ik kan me voorstellen dat je met 10 sites op een cheape hosting waar je voor elke MB disk betaald dit zou willen doen. Zelf zou ik gewoon kopies neerzetten van mn site per site en die meuk deployen via mn build server, mgoed.