order allow,deny in .htaccess

Status
Niet open voor verdere reacties.
Wat zegt de error_log dan precies?

Dit:

AH01276: Cannot serve directory /home/desardonix.nl/public_html/Beheer/: No matching DirectoryIndex (index.php,index.html,index.cgi,index.pl,index.xhtml,index.htm,index.shtml) found, and server-generated directory index forbidden by Options directive

Maar ten dele begrijp ik dit ook wel. Want ik heb geen index-bestand in de te beveiligen map, omdat ik dat niet nodig vond. (In een hogere map heb ik dat wel).

Alleen vond ik het niet leuk, dat ik geen inhoudsopgave kreeg van de map, als ik die achter de domeinnaam opgaf in de adresbalk. Dit is geblokkeerd via de Options directive. Maar achteraf dacht ik: "Dat is misschien maar goed ook! Dan kunnen hackers die inhoudsopgave ook niet zien! En zelf weet ik toch wel wat er in die map staat, want heel die map heb ik ook gewoon op mijn computer staan! Dus ik denk dat ik het lekker zo laat!"

Als ik achter de naam van die map ook nog de naam opgeef van een bestand in die map, dan heb ik wel toegang. En dat is alles wat ik nodig heb!

Via mijn mobieltje met een ander IP-adres kreeg ik geen toegang. En dat is ook precies zoals het moet! Wil ik later toch toegang via mijn mobieltje, dan kan ik het IP-adres van het mobieltje ook in de .htaccess opnemen.

Alleen wil ik nog zeker weten of mijn formulering van de Require helemaal goed en optimaal is. Dus deze vraag heb ik aan de hosting provider voorgelegd. Hopelijk willen ze daar even een oordeel over uitspreken, ook al waren ze van mening dat dat niet behoort tot hun werkterrein.

Heb je dan een VPS?

Ik weet zo goed als zeker, dat ik dat niet heb. Maar het is echt waar. Toen ik de .htaccess van mijn website pas had aangepast, werkte hij nog niet goed. Ik denk dat een foute .htaccess niet altijd een 500 error geeft. Het hangt er maar vanaf wat voor fout het is.

Inderdaad kan Apache niet meer herstarten bij sommige fundamentele fouten. Dit heb ik in localhost ook meer dan eens meegemaakt. Maar ik meen me te herinneren, dat dat niet bij iedere fout gebeurt.

De verouderde formule met 'order allow,deny' is mijns inziens zo'n fout waarbij Apache (nog) geen 500 error geeft.

Dank voor jouw medeleven en hulp! We zijn er mijns inziens bijna uit! Als ik meer weet laat ik het weten!
 
Vervolg: Ik heb al antwoord ontvangen van de hosting provider!

En ze lopen achter: Ik word verwezen naar de 'order allow,deny'-formule.

Maar die geldt voor Apache tot en met versie 2.2! Vanaf versie 2.4 moet men met Require gaan werken!

Dit zegt de website van Apache zelf ook. Alleen was de verdere uitleg van Apache niet duidelijk genoeg voor mij.

Vroeg of laat ga ik waarschijnlijk nog wel naar andere mensen schrijven om de exacte Require-formule uit te vinden.
 
Je doet alsof het rocket-science is, terwijl het echt supersimpel is:
Apache 2.4:
Code:
<RequireAll>
    Require ip 111.111.111.111
</RequireAll>

En bij Apache 2.2:
Code:
Order Deny,Allow
Deny from all
Allow from 111.111.111.111

Ik heb overigens nog nooit eerder gehoord dat een gebruiker met een foute .htaccess heel Apache plat kan leggen. Ik denk eerder dat de oorzaak ergens anders lag.
 
Laatst bewerkt:
Op sommige websites lees ik dat het <RequireAny> is in plaats van <RequireAll>. Hoe kan ik nu weten wat het werkelijk is?

Verder zeg je:
Ik heb overigens nog nooit eerder gehoord dat een gebruiker met een foute .htaccess heel Apache plat kan leggen. Ik denk eerder dat de oorzaak ergens anders lag.

Natuurlijk kan ik met een foute .htaccess heel Apache van de hostingprovider niet platleggen. Dit heb ik ook geen ogenblik gedacht. Wel kon Apache van mijn localhost even geblokkeerd worden, nadat ik het configuratiebestand httpd.conf verkeerd geconfigureerd had. Maar bij de hostingprovider heb ik niet eens toegang tot het bestand httpd.conf.

Wel kon het volgens mij even duren alvorens Apache van de hostingprovider mijn gewijzigde .htaccess had doorgenomen. Als ik bij machte zou zijn geweest om Apache van de hostingprovider even uit en aan te zetten, dan had hij het gewijzigde .htaccess-bestand mijns inziens eerder verwerkt.

Dit is volgens mij de reden, dat mijn wijziging van .htaccess eerst niet scheen te helpen. En dat gaf bij mij het verkeerde vermoeden, dat ik .htaccess nog steeds totaal verkeerd had geformuleerd. En nog steeds vraag ik mij af wat beter is: <RequireAny> of <RequireAll>.
 
Daarom zijn de directe manuals altijd beter dan blogjes van externe partijen... ;-)
 
Helemaal mee eens! Tot die conclusie was ik ook al gekomen! Maar ik moet het nog wel kunnen snappen. Anders zoek ik toch weer in andere informatiebronnen.

Hopelijk heb ik nu gelijk mijn eigen hosting provider wakker geschud. Ook zijn opvattingen waren verouderd! Zelf werd ik wakker doordat ik geen toegang meer had tot mijn eigen beveiligde map. Op andere momenten had ik zelfs toegang tot die map vanuit een IP-adres, dat niet in .htaccess stond. En dat lag niet aan de Option directive van de hosting provider!
 
Ik ben er helemaal uit! Ik kan het beste dit gebruiken:

<RequireAny>
Require ip (mijn IP volgens IPv4)
Require ip (mijn IP volgens IPv6)
</RequireAny>

Misschien is het niet meer nodig om mijn IP volgens IPv4 nog op te geven. (Ik weet nog niet in hoeverre de uitrol van IPv6 al heeft plaatsgevonden. Daarom vermeld ik voor de zekerheid mijn IP volgens IPv4 ook nog maar).

Maar het zou ronduit verkeerd zijn, als ik hier in plaats van <RequireAny> zou gebruiken: <RequireAll>.

Want dan zou de server beide IP-adressen tegelijk moeten vinden. En op den duur zal mijn IP volgens IPv4 helemaal niet meer in gebruik zijn, en niet meer herkend worden. In dat geval zou ik met <RequireAll> in dezelfde formule opnieuw geen toegang meer krijgen tot de beveiligde map!

'Any' wil namelijk zeggen: Als aan 1 van de voorwaarden is voldaan, is het al goed. 'All' wil hier zeggen: Aan beide voorwaarden moet zijn voldaan.

Dank voor jouw hulp en ook dank voor de opmerking over rocket science! Ik vond dat wel leuk. Ik kende die uitdrukking nog niet, maar nu wel !
 
Even rustig ik vermoed dat je niet op het path kan niet http niet ftp ...
Dat is logisch en dus ook veilig ...
Dus moet ik even weten of je aan de server kan of niet...
installeren van putty
het ip van je server ... open ssh ... geef user en wachtwoord... wat zie je dan .
je kan console zien je kan in een map zitten
probeer alvast eens dir aan de directory namen zou je kunnen achterhalen waar je ergens zit op de server.
 
Hallo kenikavanbis,

Helaas begrijp ik jouw vragen niet. Maar waarom zou ik nog verder zoeken? Het systeem werkt nu precies zoals ik het hebben wil. En de theorie erachter begrijp ik ook. Ook weet ik welke beperking er is opgenomen in de Option directive van de hosting provider. En die beperking is ook zoals ik het hebben wil.

Dus nogmaals: Waarom zou ik nog verder zoeken? Dit probleem is opgelost. Maar ik geef de mensen nog even de gelegenheid om te reageren. Dit moet er echter niet toe leiden, dat we eindeloos proberen om iets op te lossen, wat al opgelost is.
 
Ik snap wederom (weer) ook niks van zijn replie.
 
Ik ben dus niet de enige, die hem niet begreep!

Het enige dat ik wel begreep is dat hij mij het programma Putty aanbeveelt. Putty ken ik wel. Maar ik heb het nu niet nodig.

Voor de directe communicatie met de server van de hosting provider heb ik al FileZilla en bovendien de hostingmanager van de hosting provider. Putty wordt ook gebruikt voor het kopiëren van de inhoud van databases. Maar daarvoor gebruik ik zelfgemaakte software, en die doet het nog beter dan officiële software, omdat mijn programma's met vrijwel alle versies van de databases kunnen werken.

Maar ik ben iedereen dankbaar die mij geholpen heeft of wilde helpen! :love::love::love:
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan