Twee doelen tegelijk bereiken met htaccess

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Bas hooff

bas hooff

12/01/2019 10:49:53
Quote Anchor link
Beste PHP'ers,

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)
PHP script in nieuw venster Selecteer het PHP script
1
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
 
PHP hulp

PHP hulp

19/06/2019 18:09:08
 
Adoptive Solution

Adoptive Solution

12/01/2019 10:56:32
Quote Anchor link
Maak een subdomein aan.
Dan heb je een eigen root en zit je anderen niet in de weg.
En dan niemand vertellen hoe dat subdomein heet.
 
- Ariën -
Beheerder

- Ariën -

12/01/2019 11:05:50
Quote Anchor link
Persoonlijk raad ik aan om op een tijdelijk adres te werken. Zoals een test-domein (tip: me.uk is goedkoop) of een subdomein.
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 -
 
Bas hooff

bas hooff

12/01/2019 11:12:47
Quote Anchor link
Hi 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
 
- Ariën -
Beheerder

- Ariën -

12/01/2019 11:35:24
Quote Anchor link
Een 500 Error kan je prima uitlezen in je Error-logs.
 
Bas hooff

bas hooff

12/01/2019 11:44:50
Quote Anchor link
Ik denk dat dit de foutmelding is, redelijk zelf verklarend maar ik heb geen oplossing, want de index is 100% aanwezig.

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
 
- Ariën -
Beheerder

- Ariën -

12/01/2019 12:13:40
Quote Anchor link
Hm, het lijkt erop dat er een error-pagina wordt aangeroepenm die niet bestaat?
Want hij kijkt naar /error_docs.
 
Rob Doemaarwat

Rob Doemaarwat

12/01/2019 13:13:12
Quote Anchor link
Ben je de enige die op deze test-/ontwikkelomgeving werkt? Maak dan gewoon een "fatasiedomeinnaam" aan en zet die in je lokale hosts bestand.
 
Bas hooff

bas hooff

12/01/2019 15:44:35
Quote Anchor link
Ariën, wel vreemd angezien de redirect wel goed gaat zonder de laatste regels code om .htpasswd aan te roepen. Ik ga kijken of ik met jouw antwoord verder kom. Tnx
 
Thomas van den Heuvel

Thomas van den Heuvel

12/01/2019 16:17:31
Quote Anchor link
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
 
Bas hooff

bas hooff

12/01/2019 17:17:03
Quote Anchor link
Ik was in eerste instantie van mening dat dit een prima manier was. Ik ben - net zoals mijn omgeving - geen pro. Het migreren van de ene omgeving naar de andere is overigens geen probleem, er is dan ook niks specifiek in de URL vastgelegd o.i.d.
 
Thomas van den Heuvel

Thomas van den Heuvel

12/01/2019 17:22:20
Quote Anchor link
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.
Gewijzigd op 12/01/2019 17:23:58 door Thomas van den Heuvel
 
Bas hooff

bas hooff

12/01/2019 17:23:38
Quote Anchor link
Wat is er eigenlijk mis mee om de site te ontwikkelen in de omgeving waar de website uiteindelijk ook terecht komt ?
 
Thomas van den Heuvel

Thomas van den Heuvel

12/01/2019 17:25:43
Quote Anchor link
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.
Gewijzigd op 12/01/2019 17:51:38 door Thomas van den Heuvel
 
Bas hooff

bas hooff

12/01/2019 18:40:58
Quote Anchor link
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 :)
 
Thomas van den Heuvel

Thomas van den Heuvel

12/01/2019 22:52:40
Quote Anchor link
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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.