order allow,deny in .htaccess

Hallo,

Jarenlang heb ik een bepaalde map van de bestanden van mijn website met succes kunnen beveiligen met 'order allow,deny' in .htaccess, zodat ik alleen zelf toegang had tot de map en niemand anders. Daarbij gebruikte ik het eenvoudige ontwerp:

order allow,deny
allow from (en dan volgt mijn eigen ip-adres)

Maar nu werkt het niet meer. Ik krijg zelf geen toegang meer tot de map met dit ontwerp. Ik vermoed dat dit komt doordat KPN aan mijn computer of router een nieuw IP-adres van het nieuwe systeem IPv6 geeft gegeven. Dat nieuwe IP-adres heb ik in het ontwerp ingevoerd, maar zonder resultaat.

Hoe kan ik dit oplossen, zodat ik zelf weer toegang krijg tot de map, maar andere mensen niet?

Ik werk met Windows 7 en met een Apache-server.

Is Apache ook ingesteld op IPv6?
Probeer anders je IPv4 IP-adres eens?

Als je PHP hebt, bekijk je IP adres eens (niet via localhost)

Ik weet niet of Apache is ingesteld op IPv6. Waar kan ik dat zien en ev. aanpassen?

Mijn IPv4 IP-adres heb ik al geprobeerd. Dit werkt ook niet meer.

Via echo $_SERVER['REMOTE_ADDR']; in PHP krijg ik 127.0.0.1. En dat is heel verrassend. Want dat is gewoon van localhost.

Inderdaad werk ik in localhost. Ik dacht dat bij localhost ook gewoon gekeken zou worden naar het echte IP-adres van mijn computer of router!

Natuurlijk behoef ik mijn localhost niet zo te beveiligen. Maar ik dacht steeds: Als het in localhost niet eens lukt, dan zal het bij mijn echte website ook niet lukken. Bij mijn echte website heb ik geen toegang tot het configuratiebestand httpd.conf. Dat heeft alleen de hosting provider. Daarom is localhost steeds mijn proeftuintje.

Roep je server eens aan via je externe IP, en niet via localhost zoals ik zei.

Verder is toegang tot http.conf niet eens nodig, want dat kan prima in .htaccess.

Hoe roep ik mijn server aan via mijn externe IP?

Ik heb mijn website in localhost direct benaderd vanuit de browser Mozilla Firefox. Maar bij de oude browser Internet Explorer had ik ook problemen.
Dus het uitgangspunt (de browser) had niets met localhost te maken. Daarom vind ik het zo vreemd, dat het systeem doet alsof localhost het uitgangspunt is.

Is de server wel vanaf buiten bereikbaar? En is dat de bedoeling? Of moet deze enkel over je eigen netwerk bereikbaar zijn? Geef graag even meer context over de situatie.

Ik vertel alles wat ik weet. (Afgezien van de IP-adressen. Want ik dacht dat die persoonlijk moeten blijven).

Ik weet niet beter of de server is van buitenaf bereikbaar. Mijn uitgangspunt is immers de browser. Wel typ ik in de adresbalk localhost/ en daarachter de locatie van de map die ik wil beveiligen.

Op mijn computer met Windows 7 heb ik in C: de map xampp, en daarin de map htdocs, en daarin de map met alle bestanden van de website. En daar zit weer de map in die ik wil beveiligen. In het configuratiebestand heb ik dit pad aangegeven, zodat Apache weet waar hij de bestanden zoeken moet.

Dit werkt altijd goed behalve bij .htaccess.

Ik heb ook gelezen, dat de constructie order allow,deny verouderd is. Voor apache 2.4 moet ik in plaats daarvan werken met orderregel(s) tussen <RequireAll> en </RequireAll>, of <RequireAny> en </RequireAny>
Zo'n orderregel ziet eruit als Require ip (en dan het ip-adres).

Maar ook met Require krijg ik geen toegang tot de map, die ik aanroep via localhost in de adresbalk.

Laat eens zien wat er in staat?
Laat desnoods de laatste twee delen weg hier op het forum..

Als het een extern ip-adres is, Komt dit overeen met wat er staat op WatZijnMijnIPs.nl?

Het is de website van mijn boekhandel. De website in localhost komt exact overeen met de echte website. En dat is geweldig fijn, want alles wat ik op mijn echte website wil plaatsen via FileZilla, of via de hostingmanager van de hostingprovider, kan ik eerst in localhost plaatsen en uitproberen.

Bij mijn echte website heb ik ook een beveiligde map via 'order allow,deny' in .htaccess. En daar werkt het ook helemaal niet goed meer. (Vroeger wel !). Maar misschien komt dat doordat 'order allow,deny' verouderd is en vervangen moet worden door Require-functies. Dit zou ik nog eens een keer uit kunnen proberen bij mijn echte website. Maar ik doe even rustig aan, want ik heb zo ongeveer 12 uren achter elkaar doorgewerkt en geworsteld met pogingen om dit probleem op te lossen.

In localhost werkt het in ieder geval ook niet met Require-functies. Ik weet werkelijk niet hoe ik mijn computer duidelijk kan maken, dat niet localhost de afzender van de opdracht is, maar ikzelf via de browser, met mijn eigen IP-adressen. (Ik heb 2 browsers geprobeerd).

Websites om mijn eigen IP-adressen te achterhalen ken ik al lang. Bij het gebruik van WatZijnMijnIPs.nl krijg ik inderdaad ook mijn eigen IP-adressen, die ik al lang kende. Want daardoor kon ik mijn IP-adressen ook opgeven bij 'order allow,deny' en bij Require.

Het probleem is dus vooral, dat ik niet weet hoe ik mijn computer duidelijk kan maken, dat ikzelf de afzender van de opdracht ben, en niet localhost. Localhost is alleen de ontvanger van de opdracht.

Wat staat er nu dan in je configuratie?

Bedoel je in .htaccess van mijn echte website of van localhost?

In localhost:

<RequireAny>
Require ip (en dan volgt mijn eigen IPv4-adres)
Require ip (en dan volgt mijn eigen IPv6-adres)
</RequireAny>

Bij mijn echte website:

order allow,deny
allow from (en dan volgt mijn eigen IPv4-adres)

Bij verdere experimenten ga ik de .htaccess van localhost naar mijn echte website kopiëren.

Maar dan moet ik eerst een backup maken van de oude .htaccess van mijn echte website. En bij zulke dingen sputteren de programma's vaak tegen, omdat .htaccess met een punt begint. Dus daar wil ik even de tijd voor nemen.

Binnen de map, die ik wil beveiligen, staan ongeveer 80 bestanden. Dit zijn bijna allemaal php-bestanden, waarmee ik o.a. de bestellingen van mijn klanten ontvang, en toegang krijg tot mijn kasboeken.

Je gebruikt localhost om te testen? En die server is dus niet van buitenaf oproepbaar via https://w.x.y.z (maar dan met jouw IP-adres)?
Dan hoef je daar niks te beveiligen, of gebruik dan 127.0.0.1

Bij je eigen site die live en dus in productie draait, daar gebruik je dan het IPv4 adres van je externe IP-adres die je van je provider krijgt.
Maar is een .htaccess met .htpasswd niet handiger? Stel dat je op vakantie bent en het IP-adres is veranderd, dan heb je geen toegang meer.

Misschien is het nog handiger om de toegangscontrole in je applicatie te bouwen.

Inderdaad is mijn computer niet oproepbaar via https://w.x.y.z (Maar dan met mijn IPv4 of IPv6 adres). Ik heb het zojuist geprobeerd. Bij IPv4 krijg ik een foutmelding. Bij IPv6 wordt het adres doorgegeven aan Google. (En dat is op zich ook weer merkwaardig, want ik had Google helemaal niet opgeroepen. En Google kan er ook niets bijzonders mee).

Natuurlijk behoef ik in localhost niets te beveiligen. Dat had ik zelf al eerder gezegd. Maar het gaat mij om het principe. Als het niet lukt bij localhost, dan lukt het waarschijnlijk ook niet bij mijn echte website.

En inderdaad: Ik heb nu de Require-functies overgebracht naar .htaccess van mijn echte website (na eerst een backup gemaakt te hebben van de oude .htaccess). En daar werkt het ook helemaal niet. Ik krijg zelf geen toegang meer tot de beveiligde map. Dus het probleem is nog onopgelost en heeft uiteindelijk niets te maken met mijn localhost. Het werkt gewoon nergens.

Inderdaad kan ik in .htaccess van mijn echte website een IP-adres van de provider opgeven. Maar dan heb ik vanaf mijn eigen computer ook geen toegang meer tot de beveiligde map. Want .htaccess kijkt naar het IP-adres van de persoon die de website benadert. Zo is het tenminste altijd geweest en zo werkte het vroeger ook altijd prima.

Ja, ik had al lang overwogen om te gaan werken met .htpasswd. Maar ik vond het zo makkelijk, dat ik bij het benaderen van de beveiligde map geen wachtwoord behoefde op te geven. Want ik gebruikte die beveiligde map vrij veel.

In tijden van vakantie, als het IP-adres verandert, heb ik waarschijnlijk geen probleem. Want hoogstwaarschijnlijk kan ik met FileZilla vanaf mijn mobieltje het .htaccess-bestand van mijn echte website net zo vaak wijzigen, als ik maar wil.

Verder zeg je: "Misschien is het nog handiger om de toegangscontrole in je applicatie te bouwen." Hoe bedoel je dat? Hoe kan ik dat doen?

Ik denk dat je beter kan uitzoeken welke wijziging er plaats heeft gevonden dat het niet meer werkt. Het gebeurt niet zomaar.

Vanderploeg zei:

Verder zeg je: "Misschien is het nog handiger om de toegangscontrole in je applicatie te bouwen." Hoe bedoel je dat? Hoe kan ik dat doen?

Klik om te vergroten...

Bouw een inlogsysteem in je site, met logging en eventueel een permissie-systeem die bepaalt wie wat mag doen.

Ik denk dat je beter kan uitzoeken welke wijziging er plaats heeft gevonden dat het niet meer werkt. Het gebeurt niet zomaar.

Klik om te vergroten...

Natuurlijk! Daarom ben ik eerst 12 uren aan het zoeken geweest op internet. En op andere tijden ook nog. Ik ga echt niet zomaar mijn vraag op een forum plaatsen, zonder eerst zelf grondig gezocht te hebben. Maar ik kwam er niet uit. Dingen, die mensen op het internet schrijven, zijn nogal eens in strijd met elkaar.

Bij andere uitleggingen worden dingen als bekend verondersteld, terwijl ik die nog niet weet. Vaak ben ik dan weer uren bezig om die onbekende dingen te bestuderen. Maar het is oeverloos. Ik heb 35 jaren ervaring met computers en ik programmeer ook. Maar wat ik weet is nog maar een hele kleine fractie van wat er te weten valt. Als ik 10.000 jaren zou studeren (gesteld dat ik zo lang zou leven) dan zou ik nog maar een fractie weten van wat er te weten valt op computergebied. Bovendien veranderen de dingen steeds. Programma's die ik in 1990 maakte, worden soms automatisch door Windows verwijderd, omdat Windows ze niet meer herkent. (Dit heb ik meegemaakt. Een virusscanner zou hetzelfde kunnen doen).

Andere uitleggingen op internet zijn gewoon te lang. Het is dan een heel boekwerk, soms zelfs van honderden bladzijden, als het uitgeprint zou worden. En dan worden ook heel veel dingen gezegd, waar ik niets aan heb.

Kortom: Ik kwam er niet uit, en als laatste redmiddel ging ik toen naar dit forum.

Bouw een inlogsysteem in je site, met logging en eventueel een permissie-systeem die bepaalt wie wat mag doen.

Klik om te vergroten...

Inderdaad kan ik dat doen. Maar bij zo'n logging systeem moet ik elke keer zelf ook weer inloggen. (Ik heb het dus over het beveiligde gedeelte). En ik vond het zo makkelijk, dat ik vaak even kan kijken of er nieuwe bestellingen zijn, zonder steeds zelf in te loggen.

Vanderploeg zei:

Natuurlijk! Daarom ben ik eerst 12 uren aan het zoeken geweest op internet. En op andere tijden ook nog. Ik ga echt niet zomaar mijn vraag op een forum plaatsen, zonder eerst zelf grondig gezocht te hebben. Maar ik kwam er niet uit. Dingen, die mensen op het internet schrijven, zijn nogal eens in strijd met elkaar.

Klik om te vergroten...

Nee, als je hosting misschien een wijziging gedaan heeft waardoor het niet werkt, dan vind je dat niet zomaar op internet terug. Misschien in een openbare wijzigingslijst of een mailing van ze.
Dus ga uitzoeken op welk moment het niet werkte, en wat er veranderd is. Het gebeurt niet zomaar. Een paar mailtjes sturen naar de betrokken partijen, en je kan al in een no-time duidelijkheid hebben.
Beter dat dan 12 uur blindstaren wat misschien resulteert in tunnelvisie.

Inderdaad kan ik dat doen. Maar bij zo'n logging systeem moet ik elke keer zelf ook weer inloggen. (Ik heb het dus over het beveiligde gedeelte). En ik vond het zo makkelijk, dat ik vaak even kan kijken of er nieuwe bestellingen zijn, zonder steeds zelf in te loggen.

Klik om te vergroten...

Sowieso is een inlogsysteem het veiligst.
Ook daar kan je overigens in je browser het wachtwoord opslaan (maakt het niet veiliger), dus je stelling dat het makkelijker gaat, gaat niet echt op. Maar je hebt wel meer controle over de toegang.

Een paar mailtjes sturen naar de betrokken partijen, en je kan al in een no-time duidelijkheid hebben.

Klik om te vergroten...

Dat is goed. Dit ga ik nog proberen bij mijn hosting provider. Maar ik geef mezelf niet veel kans hierbij. Want:
1. In localhost werkte het ook niet. Tot nu toe is mijn ervaring: Alles wat lukt op mijn echte website, lukt ook in localhost, zodat ik alles eerst in localhost kan uitproberen.
2. Ik meen me te herinneren, dat de hostingprovider vroeger al aan mij geschreven heeft, dat ze geen service geven op het gebied van .htaccess, waar het gaat over het toelaten van een IP-adres en het blokkeren van andere. Want dat lag gewoon buiten hun werkterrein. Normaal gesproken bemoeien ze zich daar niet mee.

Inderdaad ga ik uiteindelijk wel werken met een inlogsysteem, als het met geen mogelijkheid lukt op de manier die ik gewend was. Maar het bevredigt natuurlijk niet, dat het niet lukt met .htaccess, terwijl daar veel over geschreven wordt op het internet.

Een inlogsysteem heeft ook het nadeel, dat het wachtwoord achterhaald kan worden door hackers. Google maakte mij erop attent, dat verschillende wachtwoorden van mij, die ik gebruikte voor webwinkels, gehackt en dus bekend waren. Deze heb ik nu gewijzigd. Maar toch.... absoluut veilig is het niet.

In localhost werkt het niet, omdat je die lokaal benadert. Dus een extern IP op de whitelist zal nooit werken, tenzij het vanaf buiten af benaderbaar is.
En als je hosting niet echt welwillend is om ondersteuning op een simpele .htaccess te geven, dan zegt dat meer over die hosting.
Heb je al in de error_log gekeken wat er misgaat? Misschien staat daar wel een hint in?

Verder kan een wachtwoord achterhaald worden door hacker, daar heb je gelijk in. Maar ze hebben er niks aan als je een 2FA (Twee-staps authenticatie) opzet.
Dit kan bijvoorbeeld met Google Authenticator en een bijbehorende library.

Het kost misschien wat tijd, maar dan heb je wel wat veiligs gemaakt door na elke inlog even de code te scannen of over te typen, en de response-code terug te geven.
Een beetje het idee hoe het inlogsysteem van internetbankieren werkt.

Inderdaad staat er in het logbestand van de hostingprovider iets over het probleem. Hierover ga ik doorvragen bij de provider. Er staat iets over de Options directive. En ik weet nog niet waar ik die vinden kan, en of ik die aan kan passen zonder hulp van de provider.

De vorige keer, toen ik .htaccess van de te beveiligen map van mijn website had veranderd, had ik het probleem, dat ik de Apache-server van de provider niet kon herstarten. In localhost kan ik dat wel, maar ik heb maar beperkt toegang tot de bestanden van de provider.

Waarschijnlijk heeft de Apache server van de provider nu inmiddels wel mijn nieuwe .htaccess doorgenomen. Het werkt nu gedeeltelijk wel en gedeeltelijk niet, zoals ik het hebben wil. Ik wil vooral weten of mijn opgegeven Require-functies helemaal correct zijn. Vooral om die reden ben ik gaan schrijven op dit forum.

Twee-staps authenticatie ken ik heel goed, in die zin dat ik het vele keren moet gebruiken bij het inloggen bij mijn bank en andere organisaties. Maar het leek me nog niet nodig om dat te gebruiken voor het beveiligde gedeelte van mijn boekhandels-website, mits .htaccess werkt zoals ik het hebben wil.

Over enkele maanden ga ik misschien een heel nieuw bedrijf opstarten. En hoogstwaarschijnlijk wil ik daar wel twee-staps authenticatie gaan toepassen voor mijn nieuwe klanten.

Natuurlijk wil ik het laten weten, als ik antwoord heb ontvangen van mijn hostingprovider.

Vanderploeg zei:

Inderdaad staat er in het logbestand van de hostingprovider iets over het probleem. Hierover ga ik doorvragen bij de provider. Er staat iets over de Options directive. En ik weet nog niet waar ik die vinden kan, en of ik die aan kan passen zonder hulp van de provider.

Klik om te vergroten...

Wat zegt de error_log dan precies?

De vorige keer, toen ik .htaccess van de te beveiligen map van mijn website had veranderd, had ik het probleem, dat ik de Apache-server van de provider niet kon herstarten. In localhost kan ik dat wel, maar ik heb maar beperkt toegang tot de bestanden van de provider.

Klik om te vergroten...

Dat is gek. Heb je dan een VPS? En ook vind ik dat frappant omdat een foute .htaccess een 500 error geeft. Bij een foute https.conf kan Apache zich niet meer herstarten.

Waarschijnlijk heeft de Apache server van de provider nu inmiddels wel mijn nieuwe .htaccess doorgenomen. Het werkt nu gedeeltelijk wel en gedeeltelijk niet, zoals ik het hebben wil. Ik wil vooral weten of mijn opgegeven Require-functies helemaal correct zijn. Vooral om die reden ben ik gaan schrijven op dit forum.

Klik om te vergroten...

Gedeeltelijk wel en gedeeltelijk niet? Wat werkt wel, en wat weer niet?

Twee-staps authenticatie ken ik heel goed, in die zin dat ik het vele keren moet gebruiken bij het inloggen bij mijn bank en andere organisaties. Maar het leek me nog niet nodig om dat te gebruiken voor het beveiligde gedeelte van mijn boekhandels-website, mits .htaccess werkt zoals ik het hebben wil.

Over enkele maanden ga ik misschien een heel nieuw bedrijf opstarten. En hoogstwaarschijnlijk wil ik daar wel twee-staps authenticatie gaan toepassen voor mijn nieuwe klanten.

Klik om te vergroten...

Zeker een aanrader, je hebt meer controle over de beveiliging.

Natuurlijk wil ik het laten weten, als ik antwoord heb ontvangen van mijn hostingprovider.

Klik om te vergroten...

We zijn benieuwd!