Ik gebruik htaccess op dit moment voor twee doeleinden. Aangezien de site in ontwikkeling is, maar dit wel op de productieomgeving wil doen, scherm ik deze af dmv htpasswd. Daarnaast maak ik ook gebruik van een routing systeem waardoor ik elke bezoeker doorstuur naar de index. Deze twee lijken niet samen te gaan. Heeft iemand een suggestie ?
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]
AuthType Basic
AuthName "Website is in ontwikkeling"
AuthUserFile .htpasswd
Require valid-user
Een alternatief is een regel die alles wat niet voldoet aan een IP-whitelist dat die worden doorgestuurd naar een "under construction" pagina, dit lijkt mij technisch want minder ingrijpend dan het meesturen van authenticatie-headers.
En ja, live ontwikkelen is nog steeds niet optimaal.
EDIT: ook kan het helpen als de applicatie zelf voorzieningen heeft voor het geven/weigeren van toegang tot pagina's. Dus een soort van user-entiteit met rechten en rollen. Die vervolgens aan pagina's gekoppeld kan worden. Op die manier kun je dit allemaal binnen je applicatie regelen en on-the-fly aanpassen, in plaats van het rommelen in je .htaccess-bestand.
Wat als er straks aanpassingen verricht moeten worden in het opgeleverde systeem? In het ergste geval gaat je applicatie onderuit als je ergens een typefout maakt ofzo. Daar kunnen gebruikers en bezoekers hinder van ondervinden, en het staat nogal onprofessioneel.
Zou jij een niet werkende site herbezoeken?
Metafoor: zou jij in een huis-in-aanbouw willen wonen, en ook kan je de badkamer niet bepaald gebruiken als deze gerenoveerd wordt.
En zelfs als je de ontwikkelsite en productiesite gescheiden houdt maar langs elkaar zet is de kans aanwezig dat je per ongeluk in de live database zit te prutten, of per ongeluk een instelling verkeerd hebt staan waardoor je testmailing (inclusief scheldwoorden of frustratie) naar de buitenwereld wordt gestuurd. Dit wil je gewoon gescheiden houden.
Ook staat de productieomgeving vaak remote, en mogelijk kun je daar niet altijd bij. Als je dan geen lokale ontwikkelomgeving hebt, dan kun je niet zoveel. Of zijn er problemen waardoor de live site plat ligt, dan wil je wellicht op een andere plek kijken wat er aan scheelt.
Het werkt doorgaans gewoon beter als deze omgevingen gescheiden van elkaar bestaan.
Hiermee spreid je ook risico. Als alles op één fysiek systeem of geografische locatie staat, en dat systeem kuren gaat vertonen of de locatie brandt af ofzo. Heb je dan nog een backup van code ergens? Alles op 1 plek onderbrengen, daarmee creëer je zelf min of meer een soort van single point of failure.
Jullie hebben ook zeker gelijk. Wellicht was ik niet geheel duidelijk door het gebruik van productie, het is niet zo dat er bezoekers op de website komen. Het gaat dus ook niet om de doorontwikkeling van een applicatie.
Voor de first-release zou ik de applicatie wel graag draaiend willen houden op mijn domein. Geïnteresseerde partijen die samen willen werken kunnen zo ook makkelijk testen door in te loggen via htpasswd. Mocht het tot een samenwerking komen dan zijn er meer mogelijkheden voor OTAP en verdere professionalisering.
Ik sta open voor de gouden tip m.b.t. mijn vraagstuk :)
2 x RewriteEngine On is in ieder geval niet nodig.
Heb je beide al eens in afzondering geprobeerd?
Dus eerst test je je rewriterules, en dan (in afzondering) de authenticatie.
Als 1 van de 2 niet werkt (en het andere wel) dan heb je je zoekgebied al gehalveerd.
Of wat zijn de symptomen nu precies? Authenticatie wordt niet opgepikt? Error 500 pagina's? Iets anders?
Misschien is het ook handig om de authenticatie op te nemen als conditie met LA-U:REMOTE_USER.
Deze problematiek heb je trouwens allemaal niet als je ofwel authenticatie regelt in de applicatie zelf of gebruik maakt van toegang op basis van IP, zoals eerder voorgesteld. Dit lijkt mij beide simpeler, omdat er blijkbaar nogal wat interactie is tussen URL rewriting en deze wijze van authenticeren.
