Twee doelen tegelijk bereiken met htaccess
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 ?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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
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
Dan heb je een eigen root en zit je anderen niet in de weg.
En dan niemand vertellen hoe dat subdomein heet.
Uit ervaring weet ik dat mensen het onduidelijk vinden als ze op een productiesite opeens een wachtwoord en gebruikersnaam te zien krijgen.
Zet er gewoon een mooie landingspage met uitleg neer.
Maar om terug te komen op je probleem:
Wat gebeurt er precies? Ik heb een soortgelijke .htaccess op mijn testdomein, en die werkt verder prima i.cm. AuthType Basic en RewriteRules
Gewijzigd op 12/01/2019 11:06:20 door - Ariën -
Terechte reactie. De website is voor 85% gereed & getest. Voor de resterende 15% verhuis ik de website liever niet.
Het inloggen werkt goed, maar dan word ik doorgestuurd naar een 500 foutmelding. Het redirecten naar de index lijkt dus niet te werken in combinatie met de passwd. Geeft dit een beter beeld ?
Toevoeging: ik weet dat ik via DNS dit ook zou kunnen oplossen om de bezoeker wel een nette pagina te tonen, en zelf rechtstreeks een IP benaderen, maar dat is voor nu niet de issue.
Gewijzigd op 12/01/2019 11:24:47 door bas hooff
2019-01-07 15:03:44 Error 38.100.21.69 AH01276: Cannot serve directory /var/www/vhosts/kluswerk.nl/error_docs/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm,index.shtml) found, and server-generated directory index forbidden by Options directive
Want hij kijkt naar /error_docs.
Quote:
Aangezien de site in ontwikkeling is, maar dit wel op de productieomgeving wil doen
Waarom? Geen reden? doe het dan niet live. Dit is normaal gesproken simpelweg "not done".
Quote:
De website is voor 85% gereed & getest. Voor de resterende 15% verhuis ik de website liever niet.
Het klinkt alsof je een deployment probleem hebt. Dit zou absoluut niet moeilijk moeten zijn, tenzij je applicatie een baksteen is met hardcoded URLs ofzo? Wat belemmert jou om dit te doen als het klaar is? En als je ontwikkelomgeving niet representatief is voor je live omgeving wat ben je dan precies aan het testen?
De volgende stap is waarschijnlijk dat klanten / de opdrachtgever alvast aan de slag willen op de site, "omdat deze toch al live staat".
Op het moment dat je dit pretpark openzet voor publiek terwijl deze nog in aanbouw is... Ik denk dat je dit moet voorkomen want hiermee haal je je alleen maar (meer) ellende op de hals.
Het klinkt gewoon alsof er al een aantal andere dingen spelen die je ook echt op een andere plek, en op een andere manier, moet oplossen.
Op een gegeven moment halen dit soort quick and dirty oplossingen je gewoon in en dan zul je je technical debt alsnog moeten inlossen, maar dan met rente :).
Gewijzigd op 12/01/2019 16:28:30 door Thomas van den Heuvel
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.
Gewijzigd op 12/01/2019 17:23:58 door Thomas van den Heuvel
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.
Gewijzigd op 12/01/2019 17:51:38 door Thomas van den Heuvel
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 :)
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.