CMS in XML beveiligen

[Phuncz]

Ik heb van een goede vriend een CMS systeem gekregen om te gebruiken wat opgebouwd is uit een index.xml, content.xsl, default.css en een img-mapje voor afbeeldingkjes. Nu vroeg hij me om ervoor te zorgen dat niemand het zomaar zou jatten door die files te downloaden. Hoe kan ik dit nu beveiligen dat men die files niet zomaar kan downloaden of zien ? index.xml en de afbeeldingen boeit niet zo, maar die content.xsl en default.css is belangrijk.

Ik heb al wat opzoekwerk gedaan ivm. htaccess, maar hier kwam ik niet echt aan uit, hij beveiligt de hele dir waardoor je moet inloggen. Terwijl het dus de bedoeling is dat bezoekers de site vrij kunnen bezichtigen.

Mijn programmeerkennis is niet echt toereikend, ik hoop dat ik het zo kan redden.

[T_E_O]

De browser van de bezoeker zal toch de .xsl nodig hebben om een XSL transformatie uit te voeren. Misschien wat om de XSL transformatie server-side door asp, php of perl oid. te laten doen ?

Sta er ook even bij stil dat volgens mij lang niet elke browser een fatsoenlijke XSL(T) processor heeft.

[tjerkw]

Phuncz schreef op woensdag 23 februari 2005 @ 23:20:
Ik heb van een goede vriend een CMS systeem gekregen om te gebruiken wat opgebouwd is uit een index.xml, content.xsl, default.css en een img-mapje voor afbeeldingkjes. Nu vroeg hij me om ervoor te zorgen dat niemand het zomaar zou jatten door die files te downloaden. Hoe kan ik dit nu beveiligen dat men die files niet zomaar kan downloaden of zien ? index.xml en de afbeeldingen boeit niet zo, maar die content.xsl en default.css is belangrijk.

Ik heb al wat opzoekwerk gedaan ivm. htaccess, maar hier kwam ik niet echt aan uit, hij beveiligt de hele dir waardoor je moet inloggen. Terwijl het dus de bedoeling is dat bezoekers de site vrij kunnen bezichtigen.

Mijn programmeerkennis is niet echt toereikend, ik hoop dat ik het zo kan redden.

Waarom zou je default.css willen beveiligen? Ik neem aan dat daar de stylesheet instaat voor je xhtml?
En volgens mij pak je het goed aan.. met .htaccess zou je kunnen aangeven welke files downloadbaar zijn. Volgens mij moet je ook de permissies van de bestanden kunnen zetten met chmod. Hoe je het dan preceis moet instellen weet ik ook niet zo 1 2 3

[tjerkw]

T_E_O schreef op woensdag 23 februari 2005 @ 23:35:
De browser van de bezoeker zal toch de .xsl nodig hebben om een XSL transformatie uit te voeren. Misschien wat om de XSL transformatie server-side door asp, php of perl oid. te laten doen ?

Sta er ook even bij stil dat volgens mij lang niet elke browser een fatsoenlijke XSL(T) processor heeft.

Aangezien hij meldt dat hij de xsl wilt beveiligen kun je aannemen dat die xsl-transformatie server side wordt gedaan. Dit gebeurt tegenwoordig meestal. Want zoals je al zegt wordt xslt bij de client side nog slecht ondersteund.

Overigens: deze topic staat in de verkeerde forum. Hoort toch echt in devschuur thuis

[Phuncz]

Ow sorry, verhuis het please

Mja, ik heb een .htpasswd en .htaccess file gemaakt, maar hij pakte mijn paswoord dus niet. Ook vroeg hij voor enkel al het bekijken van de site om een login Ik heb op internet gezocht voor .htaccess, maar veel duidelijks vind ik niet welke rechten ik precies moet instellen.

Ik zal eens zien of ik met CHMOD wat kan fixen.

[T_E_O]

tjerkw schreef op woensdag 23 februari 2005 @ 23:40:
[...]


Aangezien hij meldt dat hij de xsl wilt beveiligen kun je aannemen dat die xsl-transformatie server side wordt gedaan. Dit gebeurt tegenwoordig meestal. Want zoals je al zegt wordt xslt bij de client side nog slecht ondersteund.

Daar heb ik ook aan gedacht inderdaad, maar aangezien hij 't heeft over een CMS bestaande uit een .xml, een .xsl, een .css en een mapje met plaatjes kreeg ik toch het idee dat de transformatie client-side gedaan wordt. Misschien kan TS daar wat duidelijkheid over verschaffen ?

[Phuncz]

Hij vertelde mij juist dat het dus client-side geregeld wordt. Is hier dan iets mee te doen qua beveiliging (zie TS) ?

[Verwijderd]

Een XSLt tranformatie wordt altijd client side gedaan;
XSLt is voor XML wat CSS voor HTML is: het bepaalt hoe de uitvoer gerepresenteerd wordt. Alleen is XSLt vele malen krachtiger dan CSS; je kan er zelfs algoritmen in implementeren als je zou willen

[T_E_O]

Phuncz schreef op donderdag 24 februari 2005 @ 17:21:
Hij vertelde mij juist dat het dus client-side geregeld wordt. Is hier dan iets mee te doen qua beveiliging (zie TS) ?

Nee, dan is daar niets aan te doen, want de browser van de bezoeker heeft het .xsl bestand nodig om de transformatie uit te kunnen voeren. Wat je zou kunnen doen om 't op te lossen is het maken van een php- of asp-script om de transformatie server-side te doen.

@SpHeaRe: nietes.

@mod: kan dit niet naar de devschuur ? die mensen snappen 't waarschijnlijk 'n stuk beter dan bijvoorbeeld ik.

[rb338]

Maak een map met de content die je wil beschermen, hack het script een beetje en zet dmv htaccess een wachtwoord op die map?

[ Voor 1% gewijzigd door rb338 op 24-02-2005 17:46 . Reden: typo ]

[T_E_O]

rb338 schreef op donderdag 24 februari 2005 @ 17:46:
Maak een map met de content die je wil beschermen, hack het script een beetje en zet dmv htaccess een wachtwoord op die map?

Er is geen script.

[Korakal]

Enkeltje Devschuur, W&G schijnt 't te zijn

[Savantas]

@ Korakal (of andere mod): Aangezien de beveiligingsoptie meer serverside is/zou zijn lijkt dit me meer voor die andere Devschuur (P&W)... Die weten vast beter hoe je mapjes afsluit, er een serverside php/asp/... scriptje omheen gooit.
Overigens kan je (indien server side) natuurlijk je XSLT in een ander (sub)mapje stoppen die wel afgesloten is. Je CSS is gewoon nodig voor de browser, of waren er tooltjes om dit om te vormen naar <font=...>? (I know, vloeken in de kerk enzo ,maar zoiets zou ook wel handig zijn met bv HTML-email genereren, desnoods alleen overal style=....)

[ Voor 6% gewijzigd door Savantas op 24-02-2005 23:57 . Reden: zie sig ]

[Blue-eagle]

Dumb je .xml en .xsl files onder (dus niet IN) je website root en "merge" ze met behulp van een server-side script (asp php .net - whichever).

En dat kun je uitvinden met behulp van onze goede vriend.

[Phuncz]

Phuncz schreef op woensdag 23 februari 2005 @ 23:20:
Mijn programmeerkennis is niet echt toereikend, ik hoop dat ik het zo kan redden.

Sorry hoor, maar dat is echt allemaal boven mijn niveau

[Thijsmans]

Dan stel ik voor dat je contact opneemt met je vriend en vertelt dat je niet zonder hulp aan zijn voorwaarden kan voldoen Wij kunnen hier uren blijven speculeren over hoe het CMS al dan niet misschien werkt, feit is dat die vriend het precies weet en dus ook weet wat je hoe moet beveiligen.

Overigens, ik heb nog nooit een CMS gezien dat de CM uit CMS zonder server-side gedeelte werkt, wat je nu wel suggereert (immers, alleen een .xml, .xsl en .css zal weinig data kunnen opslaan op de server).

[Blaise]

Met .HTaccess kan je al het verkeer, of verkeer naar bepaalde mappen (of bestanden) blokkeren. Met PHP kan je deze bestanden nog wel gewoon openen. Voorbeeld:

code:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/xml/beveiligdemap
RewriteRule (.*) /errors/errormelding.html

[Soultaker]

Verwijderd schreef op donderdag 24 februari 2005 @ 17:22:
Een XSLt tranformatie wordt altijd client side gedaan;
XSLt is voor XML wat CSS voor HTML is: het bepaalt hoe de uitvoer gerepresenteerd wordt. Alleen is XSLt vele malen krachtiger dan CSS; je kan er zelfs algoritmen in implementeren als je zou willen

Je kunt XSLT net zo goed server-side doen. Dat is ook de oplossing die Blue-eagle aandraagt en eigenlijk de enige oplossing die de broncode daadwerkelijk beveiligd. (Dan nog moet je zorgen dat de bestanden niet los te downloaden zijn, maar dat is een verhaal apart.) Helaas is het uitvoeren van XSLT-transformaties redelijk kostbaar, maar op een niet al te drukbezochte site moet dat de pret niet drukken.

[Phuncz]

Bedankt voor de info, ik zal het er met hem over hebben wat we gaan doen ermee ! Bedankt voor jullie moeite !!