opgelost Rechtenstructuur mappen en bestanden

Ik ga binnenkort een nieuwe site live brengen voor de vereniging waar ik lid van ben. De hoster gaf aan dat ik goed naar de rechten structuur voor mappen en bestanden moest kijken. Die begrijp ik erg goed en wil voorkomen dat 'kwaadwillenden' toegang tot de site hebben.

De Joomla documentatie geeft wel informatie over mappen en bestanden, maar ik vind dat beperkt. Daarnaast vindt de hosting plaats op windows servers en niet op linux. En ik wil niet alles dicht zetten want de content beheerders moeten wel content toe kunnen voegen.

Is er ergens een goed artikel te vinden over de beveiliging van mappen en bestanden? Als er gesproken wordt over rechten op bestanden moet dit dan bijvoorbeeld recursief gebeuren?

bvd,

Ad

Als mijn hoster dat zou aangeven, dan zou ik direct overstappen naar een andere hoster. Dit lijkt erop dat hij zelf zijn serverconfiguratie niet op orde heeft. Als een hoster zijn zaakjes op orde heeft, dan hoef jij verder niets te doen aan de rechten namelijk. Maar mocht je toch bij die hoster willen blijven: mappen 755, bestanden 644 en configuration.php 444

Hallo Astrid,

Ik heb het wat anders ervaren De hoster dacht volgens mij juist goed met me mee. Ik gebruik Akeeba kickstarter om de site live te brengen en om dit te laten werken moet ik de rechten open zetten omdat het uitpakken anders niet werkt.
Daarna moet ik de rechten binnen de site weer goed zetten. Omdat men niet alle details kent van de site kan met niet precies aangeven welke mappen beschermd moeten worden. Klinkt mij logisch in de oren.

De rechten zoals jij de aangeeft had ik ook gelezen in de joomla documentatie. vergeef me mijn wellicht wat 'domme' vraag maar is het voldoende als ik die op de individuele bestanden zet ook de hoofdmap (root) en alle mappen in de root? Of moet ik binnen de mappen ook nog rechten op bestanden en/of mappen zetten?

De vertaling naar windows rechten maak ik wel op basis van de joomla documentatie.

Ad

Het is maar net hoe je het bekijkt. Meedenken is best leuk, maar niet als je serverconfiguratie zo gammel is.

om dit te laten werken moet ik de rechten open zetten omdat het uitpakken anders niet werkt

Deze opmerking bewijst dat dus.
Maar om antwoord te geven op je vraag: Alle mappen (dus ook submappen) op 755, alle bestanden (dus ook in submappen) op 644.

Dank je wel voor wederom een snel en verduidelijkend antwoord. Daar ga ik met de provider wel uitkomen en mocht het niet bevallen kan ik altijd nog naar een andere provider. Omdat het de bestaande provider is de vereniging geen reden ziet om te veranderen laten we het zo.

Begrijp ik goed dat als ik de rechten zet zoals je aan geeft Joomla voor mij regelt dat iemand met de juiste rechten op het systeem (dus een account op de site heeft met de juiste rechten) een bestand toe kan voegen? Bij mijn eigen site zie ik dat de rechten automatisch goed worden gezet zoals je aan geeft.

Ik kan bij de provider alleen kiezen voor lezen of schrijven en vermoed dat daarom alles op lezen (bestanden en mappen) moet worden gezet. In de huidige opzet (asp.net) zijn alleen schrijfrechten toebedeeld aan een map waar men zelf content aan kan toevoegen. Ik verwacht dat Joomla dat goed voor mij regelt.

Begrijp ik goed dat als ik de rechten zet zoals je aan geeft Joomla voor mij regelt dat iemand met de juiste rechten op het systeem (dus een account op de site heeft met de juiste rechten) een bestand toe kan voegen?

Daar is zo helaas niets over te zeggen.

In overleg met de provider is alles opgelost. De schrijfrechten waren van toepassing voor de 'owner', exact op de manier waarop het ook in de documentatie staat als er met IIS wordt gehost.

Ik ga wel nog eens uitzoeken of ik rechten ergens moet inperken maar vooralsnog werkt alles als een zonnetje. Ik heb al gekeken of ik dit item kan sluiten maar kan die optie nergens vinden.

Hallo,

Fijn dat het opgelost is.
Dank je wel voor de terugkoppeling.

Je kunt in de toekomst zelf na het terugkoppelen de topic sluiten door op de groene "Dit is de oplossing" knop te klikken.
Kijk ook hier even voor een volgende keer