---

Linke til mange forskellige tekster/opskrifter.

Hvordan får man vist indholdet af en tekst/html fil, uden at skulle skrive

<!--#include file="menu.html"-->

i hver enkelt fil.

Mvh Edmund

---

Den 17-02-2010 22:12, Edmund skrev:
> Linke til mange forskellige tekster/opskrifter.
>
> Hvordan får man vist indholdet af en tekst/html fil, uden at skulle skrive
>
> <!--#include file="menu.html"-->
>
> i hver enkelt fil.

Den eneste metode, jeg lige kan komme på, er at lave en masterside og
hente indhold af hver side fra en database alt. text-fil, og så angive
siden med en querystring variabel (så man ved, hvor i DBen/filerne det
skal hentes).

En metode, som jeg ikke finder brugervenlig, undtagen i specifikke tilfælde.

F.eks.:

domæne.dk/index.asp?side=1
domæne.dk/index.asp?side=2
domæne.dk/index.asp?side=3

osv.

Efter min mening er det kun OK på sider, hvor man "filtrerer", og hvor
selve indholdet følger fuldstændigt samme mønster, ikke på hele sitet,
men folk er naturligvis velkomne til at være uenige.

Eksempler har jeg brugt her:
http://www.webdesigngruppen.dk/galleri/galleri.asp?layout=galleri

Hvor siden galleri.asp er den samme på alle filtreringer, man får ved
klik på linksne, men indholdet ændres med querystring variable.


MVH
Rune Jensen

---

Den 18-02-2010 11:12, Rune Jensen skrev:

> Efter min mening er det kun OK på sider, hvor man "filtrerer", og hvor
> selve indholdet følger fuldstændigt samme mønster, ikke på hele sitet,
> men folk er naturligvis velkomne til at være uenige.

Nu skriver du "opskrifter", og hvis det er en opskriftssamling, er det
netop en god og optimal måde at gøre det på med querystring variable -
til visning af opskrifterne, ikke nødvendigvis til resten af siden.

Hvis du bruger ASP, som noget tyder på, så prøv at spørge i
serverside.asp, så får du nok forslag til fremgangsmåde.


MVH
Rune Jensen

---

Rune Jensen frembragte:
8X
> Hvis du bruger ASP, som noget tyder på, så prøv at spørge i serverside.asp,
> så får du nok forslag til fremgangsmåde.
8X

Hvor fik du den fra?
<!--#include file="menu.html"-->
er da vist SSI...

Spørgsmålet i øvrigt, er vist dårligt formuleret.
Hvordan får man vist noget, uden at fortælle at man vil have det
vist...

Svaret er nok, at man skal organisere sit arbejde, og det kunne tyde på
at spørgeren skal includere sin menu, et niveau længere oppe end det
sker pt - som du også anviser -, og så bruge queristyring(ASP) eller
evt. SESSION(PHP), til at bestemme hvad der vælges.
Det kan blive lidt kryptisk med kun SSI - men kan sikkert lade sig
gøre.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 18-02-2010 14:15, Birger Sørensen skrev:

> Hvor fik du den fra?
> <!--#include file="menu.html"-->
> er da vist SSI...

Ja det er SSI, som jeg netop lige har afprøvet for første gang

Jeg kender absolut intet til PHP og ASP.

Mvh Edmund

---

Den 18-02-2010 15:51, Edmund skrev:
> Den 18-02-2010 14:15, Birger Sørensen skrev:
>
>> Hvor fik du den fra?
>> <!--#include file="menu.html"-->
>> er da vist SSI...
>
> Ja det er SSI, som jeg netop lige har afprøvet for første gang
>
> Jeg kender absolut intet til PHP og ASP.

Så prøv at uddybe, hvad du vil..

Har du et link til din side?


MVH
Rune Jensen

---

Den 18-02-2010 16:13, Rune Jensen skrev:

>> Jeg kender absolut intet til PHP og ASP.
>
> Så prøv at uddybe, hvad du vil..

Tror nu du har forstået spørgsmålet

Jeg har opskrifter som html filer liggende i en mappe, om dem vil jeg
linke til fra en side med en liste over disse.

Og så vil jeg gerne bevare menuen fra hovensiden.
Nu er det ikke et problem for mig at inkludere menu i de få opskrifter
jeg har, for jeg skal alligvel ind og rette i de fleste.

Men havde man rigtig mange, ville det jo være lidt træls, så jeg tænkte
om der var en mere smart metode

> Har du et link til din side?

www.edmorano.dk/opskrift/hovedret/list.shtml

I Farsrulle har jeg så inkluderet menuen
http://www.edmorano.dk/opskrift/hovedret/Farsrulle.shtml

De andre er uden menu som denne
http://www.edmorano.dk/opskrift/hovedret/brunkl.htm

Mvh Edmund

---

Den 18-02-2010 23:11, Edmund skrev:
> Den 18-02-2010 16:13, Rune Jensen skrev:
>
>>> Jeg kender absolut intet til PHP og ASP.
>>
>> Så prøv at uddybe, hvad du vil..
>
> Tror nu du har forstået spørgsmålet
>
> Jeg har opskrifter som html filer liggende i en mappe, om dem vil jeg
> linke til fra en side med en liste over disse.
>
> Og så vil jeg gerne bevare menuen fra hovensiden.
> Nu er det ikke et problem for mig at inkludere menu i de få opskrifter
> jeg har, for jeg skal alligvel ind og rette i de fleste.
>
> Men havde man rigtig mange, ville det jo være lidt træls, så jeg tænkte
> om der var en mere smart metode
>
>> Har du et link til din side?
>
> www.edmorano.dk/opskrift/hovedret/list.shtml
>
> I Farsrulle har jeg så inkluderet menuen
> http://www.edmorano.dk/opskrift/hovedret/Farsrulle.shtml
>
> De andre er uden menu som denne
> http://www.edmorano.dk/opskrift/hovedret/brunkl.htm

Idéen går (lidt simpelt) ud på, at du har nogle hoved sider. F.eks.:

Hovedret

Bagning

For-efterret & lign

Mad-links

Og de sider, hvor der er opskrifter på, skal have en querystring i
stedet for et egentligt filnavn, så f.eks. her:

http://www.edmorano.dk/opskrift/bagning/boller.html

der kan man lave siden sådan her:

http://www.edmorano.dk/opskrift/bagning.php?type=boller

I selve PHP-koden, som så ligger i filen bagning.php, der skal man hente
værdien af type efter ?-tegnet, og så kommer det tricky, at man skal
kunne slå op udfra typen hvad indholdet er. Lad os sige, hvis man har en
fil, som hedder boller.txt og en fil, som hedder brownies.txt, hvor de
respektiive opskrifter ligger. Så vil man kunne skrive nogenlunde sådan
her i filen bagning.php:

QUERY_TYPE = indholdet af variablen type

hent indholdet af filen QUERY_TYPE + ".txt"

vis indholdet i f.eks. en <p>

------

Hvis man så i adressefeltet indtaster og henter siden:

http://www.edmorano.dk/opskrift/bagning.php?type=boller

så vil ovenstpående betyde:


QUERY_TYPE="boller"

hent indholdet af filen "boller" + ".txt"

vis dette indhold.


Samme princip med

http://www.edmorano.dk/opskrift/bagning.php?type=brownies


Det hele foregår i samme fil, bagning.php, mens indholdet styres af
værdien af type, som fortæller hvilken .txt-fil, man skal have fat i.


Der er selvfølgelig en del mere til det end det, for eksempel kan man
sige, at første linje i tekst-filen altid er en <h1>, og hvis der er
mere end to carriage return, skal teksten i en <p>. Hent indhold af fil
kan laves som en function, hvis det er.

Og mere igen, for dette er en meget forsimplet udgave, hvor en del ting
ikke er taget med. Måske man ville lægge det i en database også, hvis
det er - kommer nok an på, hvor stor samlingen bliver, og hvor meget du
vil kunne søge. Med en database, vil du kunne give masser af
søgekriterier, men det kan - måske? - også være lidt vanskeligere at
bruge/lære.

Men med et sådant setup, vil du også kunne lave en admin-side, hvor du
kan indtaste direkte opskrifterne på siden, som man kun kan rette, hvis
man angiver et kodeord. Altså hvor du ikke behøver rette i selve
filerne, men det kan gøres fra hjemmesiden selv.


Giver det mening?


MVH
Rune Jensen

---

Den 19-02-2010 01:01, Rune Jensen skrev:

> Giver det mening?

Nåhjo - oversigten over opskrifterne. Hvis man placerer f.eks.
bageopskrifter i sit eget bibliotek, så er oversigten ret nem at lave,
for det er i virkeligheden en lille omskrivning af alle filnavne i det
directory.

boller.txt f.eks. der fjerner man .txt og gør b-et stort, så får man
fint Bagning. Bare en liste på samme måde over alle filer i directoriet,
og den oversigt er fuldautomatisk.

....det er nogenlunde sådan, jeg selv gør, men OK, nogle vil
sandsynligvis foreslå en database i stedet ;)


MVH
Rune Jensen

---

Den 19-02-2010 07:15, Rune Jensen skrev:

> ...det er nogenlunde sådan, jeg selv gør, men OK, nogle vil
> sandsynligvis foreslå en database i stedet ;)

Jeg vil sige, at til dette formål er en database det eneste
rigtige. Alt andet er spildt arbejde, fordi man alligevel på
et tidspunkt vil finde ud af, at det skal laves i en
database, og så skal man til at starte forfra.

Siden i min signatur er lavet i en database, selvom den kun
indeholder lidt over hundrede opslag. Det var lidt hårdt at
få det til at virke, da min viden om databaser og php på det
tidspunkt var nul og niks. Men det lykkedes med hjælp fra
nyhedsgrupperne, ikke mindst php-gruppen. Og i dag er det
simpelthen en leg at opdatere siden med nye "opskrifter".

Det vigtigste arbejde med en database er at finde ud af
hvilke felter, den skal indholde. Dette er vigtigt, fordi de
kan bruges til at søge på og dermed til at samle relevant
indhold.
Umiddelbart kan jeg forestille mig, at en opskriftsdatabase
skal indeholde felter til:
Tekst - evt. opdelt med en overskrift for sig.
Dato for tilføjelse
Forfatter
Type af ret (forret/hovedret/osv)
Tilberedningstid
Ingredienser (så kan man søge på det man har i køleskabet)
Oprindelsesland
Kødtype
Billede(r) (de skal ikke opbevares i databasen, blot links
til dem)
Sæson

Jo flere felter, jo mere avanceret søgning og
sammenstillinger kan man lave. Og bemærk, at det ikke kun er
den besøgende, der skal kunne bruge søgefunktionerne. Man
kan fx lave et link, der hedder "Sommermad" og så få
medtaget alle retter, der er markeret som værende sommermad.
Og det foregår selvfølgelig helt automatisk, så man sal ikke
ind og rette noget, når man tilføjer en ny ret sommermad.
Den medtages automatisk, når der klikkes på menupunktet.

--
Mvh. Kim Ludvigsen
http://ordforklaring.dk

---

Den 19-02-2010 01:15, Rune Jensen skrev:
> Den 19-02-2010 01:01, Rune Jensen skrev:

> boller.txt f.eks. der fjerner man .txt og gør b-et stort, så får man
> fint Bagning.

Nu kender jeg som sagt intet til php, men er overstående formuleret
rigtigt, for det er sort snak for mig :)

Nu skal du ikke komme med nærmere forklaring, jeg må lige læse lidt om
php, så vender jeg tilbage.

Men har jeg forstået det rigtigt, at man ikke kan hente en html fil, så
man har tekst formateringen på den måde, øh og evt med billed i, og dens
placering.

Nu har jeg ikke planer om en større opskrift samling, det er bare for at
prøve at lære noget, og det skal jeg da lige love for at man er nødt til :)

Mvh Edmund

---

Den 19-02-2010 23:10, Edmund skrev:

> Men har jeg forstået det rigtigt, at man ikke kan hente en html fil, så
> man har tekst formateringen på den måde, øh og evt med billed i, og dens
> placering.

Det havde jeg så misforstået, det kan man godt.



<a href="bagning.php?op=boller">boller</a>

Jeg har så brugt include i bagning.php

<?php include("../opskriftmenu.php"); ?>

<div id="indhold">

<?php
$op=$_GET['op'];
$op = $op .".php";
include($op); ?>

</div>

Tak for hjælpen

Mvh Edmund

---

Den 20-02-2010 20:58, Edmund skrev:

> <a href="bagning.php?op=boller">boller</a>
>
> Jeg har så brugt include i bagning.php
>
> <?php include("../opskriftmenu.php"); ?>
>
> <div id="indhold">
>
> <?php
> $op=$_GET['op'];
> $op = $op .".php";
> include($op); ?>
>
> </div>
>
> Tak for hjælpen

Det vidste jeg ikke, man kunne i PHP.

Hvis du bruger en løsning, hvor du bruger værdien af op til direkte at
bestemme includefilens navn, så vær lige sikker på, man kun kan indsætte
de værdier i op, som du vil have, ellers kan man jo potentielt include
hvadsomhelst fra adresselinjen.

Typisk ville man måske lave et array med lovlige værdier
(boller,brownies,kager...) og så teste op-værdien imod dette, før der
kan includes.


MVH
Rune Jensen

---

Rune Jensen skrev:

>> <?php
>> $op=$_GET['op'];
>> $op = $op .".php";
>> include($op); ?>

> Det vidste jeg ikke, man kunne i PHP.

Det kan man sagtens. Det kan man også med SSI, og sikkert også med ASP's
pendant til include().

> Typisk ville man måske lave et array med lovlige værdier
> (boller,brownies,kager...) og så teste op-værdien imod dette, før der
> kan includes.

Det hører i min verden ind under almindelig inputvalidering. Tjek det
inputtede op imod forventede værdier.

---

Rune Jensen udtrykte præcist:
> Den 20-02-2010 20:58, Edmund skrev:
>
>> <a href="bagning.php?op=boller">boller</a>
>>
>> Jeg har så brugt include i bagning.php
>>
>> <?php include("../opskriftmenu.php"); ?>
>>
>> <div id="indhold">
>>
>> <?php
>> $op=$_GET['op'];
>> $op = $op .".php";
>> include($op); ?>
>>
>> </div>
>>
>> Tak for hjælpen
>
> Det vidste jeg ikke, man kunne i PHP.
>
> Hvis du bruger en løsning, hvor du bruger værdien af op til direkte at
> bestemme includefilens navn, så vær lige sikker på, man kun kan indsætte de
> værdier i op, som du vil have, ellers kan man jo potentielt include
> hvadsomhelst fra adresselinjen.
>
> Typisk ville man måske lave et array med lovlige værdier
> (boller,brownies,kager...) og så teste op-værdien imod dette, før der kan
> includes.
>
>
> MVH
> Rune Jensen

Det er klart et sikkerhedsbrist. include kan ikke bare hente filer fra
andre servere, den kan også eksekvere dem der.
Det er oplagt, at oprette arrayet med "forkortelser
$op_tilladt = array( 'bo' => 'boller.php', 'br'=>'brownies.php', 'ka'
=> 'kager.php');
så er det (principielt) blot at kalde
include $op_tilladt[ (string)$_GET[ 'op']];
og ikke eksisterende vil blive smidt ud.
Har du mange opskrifter, skal der for hver ret der skal vises, oprettes
et stort array, med kort levetid og meget begrænet anvendelse.
Men det er en oplagt kandidat til databasen - der skal bare noget andet
sikring på $_GET...
Men ellers, prøv

<div id="indhold">
<?php
$op = (string)$_GET['op'];
$op = pathinfo( $op, PATHINFO_FILENAME).'.php';
if ( file_exists( $op)) {
include( $op);
}
else {
echo "Prøv med en side der eksisterer - det er meget
sjovere!<br>\n$op er ikke i min kogebog!";
}
?>
</div>

sikrer at kun filer i den lokale folder kan includes - og dermed kun
..php filer, du selv har skrevet, uden at skulle checke en hel masse
tilladte værdier for $_GET[ 'op'].

Men nu er vi vist på vej over i php gruppen

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 21-02-2010 02:59, Birger Sørensen skrev:
> Rune Jensen udtrykte præcist:
>> Den 20-02-2010 20:58, Edmund skrev:
>>
>>> <a href="bagning.php?op=boller">boller</a>
>>>
>>> Jeg har så brugt include i bagning.php
>>>
>>> <?php include("../opskriftmenu.php"); ?>
>>>
>>> <div id="indhold">
>>>
>>> <?php
>>> $op=$_GET['op'];
>>> $op = $op .".php";
>>> include($op); ?>
>>>
>>> </div>
>>>
>>> Tak for hjælpen
>>
>> Det vidste jeg ikke, man kunne i PHP.
>>
>> Hvis du bruger en løsning, hvor du bruger værdien af op til direkte at
>> bestemme includefilens navn, så vær lige sikker på, man kun kan
>> indsætte de værdier i op, som du vil have, ellers kan man jo
>> potentielt include hvadsomhelst fra adresselinjen.
>>
>> Typisk ville man måske lave et array med lovlige værdier
>> (boller,brownies,kager...) og så teste op-værdien imod dette, før der
>> kan includes.
>>
>>
>> MVH
>> Rune Jensen
>
> Det er klart et sikkerhedsbrist. include kan ikke bare hente filer fra
> andre servere, den kan også eksekvere dem der.
> Det er oplagt, at oprette arrayet med "forkortelser
> $op_tilladt = array( 'bo' => 'boller.php', 'br'=>'brownies.php', 'ka' =>
> 'kager.php');
> så er det (principielt) blot at kalde
> include $op_tilladt[ (string)$_GET[ 'op']];
> og ikke eksisterende vil blive smidt ud.
> Har du mange opskrifter, skal der for hver ret der skal vises, oprettes
> et stort array, med kort levetid og meget begrænet anvendelse.
> Men det er en oplagt kandidat til databasen - der skal bare noget andet
> sikring på $_GET...
> Men ellers, prøv
>
> <div id="indhold">
> <?php
> $op = (string)$_GET['op'];
> $op = pathinfo( $op, PATHINFO_FILENAME).'.php';
> if ( file_exists( $op)) {
> include( $op);
> }
> else {
> echo "Prøv med en side der eksisterer - det er meget sjovere!<br>\n$op
> er ikke i min kogebog!";
> }
> ?>
> </div>
>
> sikrer at kun filer i den lokale folder kan includes - og dermed kun
> .php filer, du selv har skrevet, uden at skulle checke en hel masse
> tilladte værdier for $_GET[ 'op'].

Det er smart, ja. Og meget nemmere at lave en file-exists i PHP, end i
ASP, hvor man først skal lave et objekt til det... Ved ikke, hvorfor MS
synes, det skal være så kompliceret ;)

I ovenstående, kan man give en 404, hvis filen ikke eksisterer. Det vil
gøre botter mindre interesserede.

I forbindelse med inputvalidering, bruger mange en generel
filtrerings-rutine, som fjerner alle skadelige karakterer, noget a la:

function RemoveBad(strTemp)
RemoveBad=replace( replace( replace( replace( replace( replace(
replace( replace( replace( replace( strTemp, "<", ""), ">", ""), ":",
""), "'", ""), chr( 34), ""), "%", ""), "&", ""), ";", ""), "(", ""),
")", "")
end function

QUERY_OP=RemoveBad(request.querystring("op")

Den er nem at forstå og bedre end ingenting, men ikke som eneste
validering. Da den er ret generel kan den bruges som et over all tjek
for f.eks. cross-site-scripting, men derudover skal man også have tjek
direkte på brugen, f.eks. netop om en given fil eksisterer.

....med over-all tjek menes, man vil formentlig kunne lave en
rewrite-rule ud af den også.

> Men nu er vi vist på vej over i php gruppen

Jeg har futtet, så svaret her bringes både her og i PHP-gruppen.


MVH
Rune Jensen

---

Efter mange tanker skrev Rune Jensen:
8X
> Det er smart, ja. Og meget nemmere at lave en file-exists i PHP, end i ASP,
> hvor man først skal lave et objekt til det... Ved ikke, hvorfor MS synes, det
> skal være så kompliceret ;)
>
> I ovenstående, kan man give en 404, hvis filen ikke eksisterer. Det vil gøre
> botter mindre interesserede.
8X

Der kan vist skrives mange og tykke bøger om ting M$ *vil* gøre tingene
anderledes end det indlysende, og vanskeligere end nødvendigt.
Jeg er holdt op med at spekulere på hvorfor. Tror ikke der er en
fornufig forklaring.
8-o

Uden at gå en hel masse i detallier, så er det ikke umiddelbart muligt
i PHP-kodestumpen, at sende 404 i stedet for en "fejlmeddelelse". Der
er allerede skrevet til siden, så headere er sendt - og det er for sent
at ændre dem.
Men med en anderledes opbygning af scriptet, så checket kommer før der
sendes noget, vil det kunne gøres.

Murphy's lov : Hvis noget *kan* gå galt så går det galt.
Altså - der skal altid checkes for at input er lovligt og brugbart,
hvor det på nogen måde kan lade sig gøre.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 21-02-2010 15:54, Birger Sørensen skrev:
> Men med en anderledes opbygning af scriptet, så checket kommer før der
> sendes noget, vil det kunne gøres.

Det kan løses med output buffering, så sendes data ikke før man enten
flusher bufferen, stopper output buffering, eller scriptet slutter.

Hvis man inden for den kode hvor buffering er aktiveret, skriver en ny
header, sætter PHP den selv på plads hvor den hører til, og det virker
dermed stadig. Så man behøver altså ikke mere end 2 linjer velplaceret
kode for at løse problemet. :)

- Chano Andersen

---

Chano Andersen forklarede den 21-02-2010:
> Den 21-02-2010 15:54, Birger Sørensen skrev:
>> Men med en anderledes opbygning af scriptet, så checket kommer før der
>> sendes noget, vil det kunne gøres.
>
> Det kan løses med output buffering, så sendes data ikke før man enten flusher
> bufferen, stopper output buffering, eller scriptet slutter.
>
> Hvis man inden for den kode hvor buffering er aktiveret, skriver en ny
> header, sætter PHP den selv på plads hvor den hører til, og det virker dermed
> stadig. Så man behøver altså ikke mere end 2 linjer velplaceret kode for at
> løse problemet. :)
>
> - Chano Andersen

OK - og tak.
Jeg har aldrig brugt output buffering i PHP, så jeg har vænnet mig til
at checke indlysende fejl eller mangler i input, og følge konsekvensen
af sådanne, inden der foretages noget i scriptet.
Men det er da bestemt en mulighed i dette tilfælde.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 21-02-2010 19:32, Birger Sørensen skrev:
> Jeg har aldrig brugt output buffering i PHP, så jeg har vænnet mig til
> at checke indlysende fejl eller mangler i input, og følge konsekvensen
> af sådanne, inden der foretages noget i scriptet.

Det er vel også den mest fornuftige måde at gøre tingene på? Det er bare
ikke altid muligt, specielt ikke hvis der er tale om andres kode, der er
det nemmere at aktivere output buffering ved at sætte en ob_start()
øverst i første fil, og så slutte den med ob_end_flush() når man har
tilføjet sine headere. (Eller bare sidst i sidste fil).

En anden mulighed er, hvis der er tale om validering af login eller
andet hvor man ikke ønsker brugeren ser eventuelt allerede genererede
data, er at smide en ob_end_clean() ind inden man laver sine egne data,
f.eks. headere. Det smider den aktuelle buffer væk (Inklusive eventuelle
headers), og man kan herefter generere sine egne data, uden at tænke
over hvad der tidligere var genereret.

> Men det er da bestemt en mulighed i dette tilfælde.

Og klart den nemmeste, hvis koden ikke tillader omstrukturering, eller
tiden ikke tillader til det.

- Chano Andersen

---

<div id="indhold">
<?php
$op = (string)$_GET['op'];
$op = pathinfo( $op, PATHINFO_FILENAME).'.php';
if ( file_exists( $op)) {
include( $op);
}
else {
echo "Prøv med en side der eksisterer - det er meget
sjovere!<br>\n$op er ikke i min kogebog!";
}
?>
</div>

Denne filtest kan ikke lide filnavne der begynder med ÆØÅ

$op = pathinfo( $op, PATHINFO_FILENAME).'.php';

Før testen er $op f.eks ="Æbler"
Efter testen er $op = "bler.php"



--
Mvh Edmund

---

Edmund frembragte:
> <div id="indhold">
> <?php
> $op = (string)$_GET['op'];
> $op = pathinfo( $op, PATHINFO_FILENAME).'.php';
> if ( file_exists( $op)) {
> include( $op);
> }
> else {
> echo "Prøv med en side der eksisterer - det er meget sjovere!<br>\n$op er
> ikke i min kogebog!";
> }
> ?>
> </div>
>
> Denne filtest kan ikke lide filnavne der begynder med ÆØÅ
>
> $op = pathinfo( $op, PATHINFO_FILENAME).'.php';
>
> Før testen er $op f.eks ="Æbler"
> Efter testen er $op = "bler.php"

Danske karakterer er altid et problem på nettet. Derfor er det en
rigtig god idé, at undgå dem. Kald din fil Aabler.php i stedet.
Det er fint med danske karakterer i filnavne - på din egen PC, hvis dit
OS kan håndtere det (og det kan de fleste i dag vel).
På nettet er det skidt, og giver dig kun problemer.

Der findes sikkert et eller andet trick. Men jeg kender det ikke.
Undgå de danske karakterer i filnavne - det er den enkleste løsning.
I øvrigt, er det også en skidt ide med store bogstaver på nettet. Hvor
filnavne på din PC er ligeglad, er det ikke sådan på nettet.
(Aabler.php er samme fil som aabler.php på din PC, men sådan er det
ikke på nettet)
Ikke en nødvendighed, for hvis du bare bruger samme blanding af store
og små bogstaver, virker tingene som de skal. Men hvis ikke...
Så en vane med kun at bruge små bogstaver i filnavne, er også rigtig
god.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 04-03-2010 12:42, Birger Sørensen skrev:

> Danske karakterer er altid et problem på nettet. Derfor er det en rigtig
> god idé, at undgå dem. Kald din fil Aabler.php i stedet.
> Det er fint med danske karakterer i filnavne - på din egen PC, hvis dit
> OS kan håndtere det (og det kan de fleste i dag vel).
> På nettet er det skidt, og giver dig kun problemer.

Ja problemer , jeg har haft dem omdøbt flere gange

Men det så ud til at virke med php, men det var i XAMPP.

> Så en vane med kun at bruge små bogstaver i filnavne, er også rigtig
> god.

Det var store bogstaver fordi jeg ville være smart og bruge selve
filnavnet som overskrift, altså echo $op.

--
Mvh Edmund

---

Edmund skrev:
> Den 04-03-2010 12:42, Birger Sørensen skrev:
>
>> Danske karakterer er altid et problem på nettet. Derfor er det en rigtig
>> god idé, at undgå dem. Kald din fil Aabler.php i stedet.
>> Det er fint med danske karakterer i filnavne - på din egen PC, hvis dit
>> OS kan håndtere det (og det kan de fleste i dag vel).
>> På nettet er det skidt, og giver dig kun problemer.
>
> Ja problemer , jeg har haft dem omdøbt flere gange
>
> Men det så ud til at virke med php, men det var i XAMPP.
>
> > Så en vane med kun at bruge små bogstaver i filnavne, er også rigtig god.
>
> Det var store bogstaver fordi jeg ville være smart og bruge selve filnavnet
> som overskrift, altså echo $op.

Det er fint nok, at bruge store bogstaver. Problemet med det, er når
man en enkelt gang gør en undtagelse...
Så går det galt. Det vigtige er en vane, som man så skal lade være at
undvige fra.
Det findes vist en funktion ( ucfirst;
http://dk2.php.net/manual/en/function.ucfirst.php ) der kan ændre det
første bogstav i en streng til stort - ved ikke om det går med de
danske, som under alle omstændigheder, ikke er en god ide i filnavne.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 04-03-2010 12:42, Birger Sørensen skrev:

>> $op = pathinfo( $op, PATHINFO_FILENAME).'.php';
>>
>> Før testen er $op f.eks ="Æbler"
>> Efter testen er $op = "bler.php"


> Der findes sikkert et eller andet trick. Men jeg kender det ikke.



<?php
$op=$_GET['op'];
$first = ord($op);// undersøger første bogstav
$opud = $op;
$op = pathinfo( $op, PATHINFO_FILENAME).'.html';
/* alle forandstillede ÆØÅ blev fjernet i $op */

   if ($first == 198) $op = "Æ" .$op;
   if ($first == 216) $op = "Ø" .$op;
   if ($first == 197) $op = "Å" .$op;
if ( file_exists($op)) {
echo "<H4>" .$opud . "</H4><br>";
include($op);
}
else {
echo "Prøv med en side der eksisterer - det er meget
sjovere!<br>\n$opud er ikke i min kogebog!";
}
?>

Nu falder du vel ned at stolen af grin

--
Mvh Edmund

---

Edmund forklarede den 09-03-2010:
> Den 04-03-2010 12:42, Birger Sørensen skrev:
>
>>> $op = pathinfo( $op, PATHINFO_FILENAME).'.php';
>>>
>>> Før testen er $op f.eks ="Æbler"
>>> Efter testen er $op = "bler.php"
>
>
>> Der findes sikkert et eller andet trick. Men jeg kender det ikke.
>
>
>
> <?php
> $op=$_GET['op'];
> $first = ord($op);// undersøger første bogstav
> $opud = $op;
> $op = pathinfo( $op, PATHINFO_FILENAME).'.html';
> /* alle forandstillede ÆØÅ blev fjernet i $op */
>
>    if ($first == 198) $op = "Æ" .$op;
>    if ($first == 216) $op = "Ø" .$op;
>    if ($first == 197) $op = "Å" .$op;
> if ( file_exists($op)) {
> echo "<H4>" .$opud . "</H4><br>";
> include($op);
> }
> else {
> echo "Prøv med en side der eksisterer - det er meget sjovere!<br>\n$opud
> er ikke i min kogebog!";
> }
> ?>
>
> Nu falder du vel ned at stolen af grin

Hvis det virker, er der vel ingen grund til at grine ad det. ^^

Hvad sker der med f.eks. Æblegrød, Nøddekage, Grønne bønner
Er det kun som første bogstav, pathinfo() ikke accepterer de danske
karakterer?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 09-03-2010 14:46, Birger Sørensen skrev:

> Hvad sker der med f.eks. Æblegrød, Nøddekage, Grønne bønner
> Er det kun som første bogstav, pathinfo() ikke accepterer de danske
> karakterer?

Ja, det er kun det første, eller de første bogstaver den klipper af.
F.eks "Øæbler" bliver til "bler"

Så "Øæbler" vil ikke virke i den løsning jeg kom med, da det kun er
første bogstav jeg klistrer på igen.

"Brunkål med oksekød" virker fint.

--
Mvh Edmund

---

Edmund forklarede:
> Den 04-03-2010 12:42, Birger Sørensen skrev:
>
>>> $op = pathinfo( $op, PATHINFO_FILENAME).'.php';
>>>
>>> Før testen er $op f.eks ="Æbler"
>>> Efter testen er $op = "bler.php"
>
>
>> Der findes sikkert et eller andet trick. Men jeg kender det ikke.
>
>
>
> <?php
> $op=$_GET['op'];
> $first = ord($op);// undersøger første bogstav
> $opud = $op;
> $op = pathinfo( $op, PATHINFO_FILENAME).'.html';
> /* alle forandstillede ÆØÅ blev fjernet i $op */
>
>    if ($first == 198) $op = "Æ" .$op;
>    if ($first == 216) $op = "Ø" .$op;
>    if ($first == 197) $op = "Å" .$op;
> if ( file_exists($op)) {
> echo "<H4>" .$opud . "</H4><br>";
> include($op);
> }
> else {
> echo "Prøv med en side der eksisterer - det er meget sjovere!<br>\n$opud
> er ikke i min kogebog!";
> }
> ?>
>
> Nu falder du vel ned at stolen af grin

Kom til at tænke på, at du kan prøve at utf8 encode strengen.
Ikke sikker på at det er det rigtige, men det kunne da være et forøg
værd.
$op = utf8_encode( $_GET['op']);
$op = utf8_decode( pathinfo( $op, PATHINFO_FILENAME).'.html');
eller du kunne prøve basename() i stedet for pathinfo(). Tror nu nok,
du vil få samme resultat - men igen, det kan ikke skade at prøve.
Dokumentationen nævner overhovedet ikke noget om karaktersæt, hverken
for den eller den anden, så det er nok et problem med OS'et og
afviklingen af PHP, der er årsag..
http://dk2.php.net/manual/en/function.pathinfo.php
http://dk2.php.net/manual/en/function.basename.php
Men det er nu stadig det sikreste at holde sig fra danske, og til små
bogstaver..

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Det er klart et sikkerhedsbrist. include kan ikke bare hente filer fra
> andre servere, den kan også eksekvere dem der.

Helt klart en sikkerhedsbrist, og det er også roden til alt ondt ;)

Men din formulering er lidt uklar, så jeg vil præcisere at det giver
mulighhed for at køre ondsindet koder _her_ og ikke _der_, altså at
installere 'ting'/overtage serveren.

> Det er oplagt, at oprette arrayet med "forkortelser

I det her tilfælde ville jeg nok synes at det er nok at tjekke at input
udelukkende består af a..z, 0..9 samt at bruge samme tegn til filnavne.

> Men det er en oplagt kandidat til databasen - der skal bare noget andet
> sikring på $_GET...

Yeps - brug parameterized queries, og du kan sove trygt og roligt udi al
fremtid ;)

(Desværre er det vist ikke så brugt i PHP verdenen, selvom 'vi' andre har
brugt det i 15+ år).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen har bragt dette til verden:
> Birger Sørensen wrote:
>
>> Det er klart et sikkerhedsbrist. include kan ikke bare hente filer fra
>> andre servere, den kan også eksekvere dem der.
>
> Helt klart en sikkerhedsbrist, og det er også roden til alt ondt ;)
>
> Men din formulering er lidt uklar, så jeg vil præcisere at det giver
> mulighhed for at køre ondsindet koder _her_ og ikke _der_, altså at
> installere 'ting'/overtage serveren.
>
>> Det er oplagt, at oprette arrayet med "forkortelser
>
> I det her tilfælde ville jeg nok synes at det er nok at tjekke at input
> udelukkende består af a..z, 0..9 samt at bruge samme tegn til filnavne.
>
>> Men det er en oplagt kandidat til databasen - der skal bare noget andet
>> sikring på $_GET...
>
> Yeps - brug parameterized queries, og du kan sove trygt og roligt udi al
> fremtid ;)
>
> (Desværre er det vist ikke så brugt i PHP verdenen, selvom 'vi' andre har
> brugt det i 15+ år).

Mener du at kodeeksemplet skulle kunne installere ting på serveren?
Det kan jeg ikke se hvordan skulle kunne foregå - men er da lydhør,
hvis det kan forklares...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Mener du at kodeeksemplet skulle kunne installere ting på serveren?
> Det kan jeg ikke se hvordan skulle kunne foregå - men er da lydhør,
> hvis det kan forklares...

Det fremgår ikke hvilket kodeeksempel du henviser til.
Jeg henviste til den kode (ikke din), der er sårbar overfor RCE (Remote Code
Execution).

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen kom med følgende:
> Birger Sørensen wrote:
>
>> Mener du at kodeeksemplet skulle kunne installere ting på serveren?
>> Det kan jeg ikke se hvordan skulle kunne foregå - men er da lydhør,
>> hvis det kan forklares...
>
> Det fremgår ikke hvilket kodeeksempel du henviser til.
> Jeg henviste til den kode (ikke din), der er sårbar overfor RCE (Remote Code
> Execution).

OK
Troede du mente mit forslag til "forbedring", da du svarede mig

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Troede du mente mit forslag til "forbedring", da du svarede mig

Årsagen til jeg svarede under dit indlæg var, at jeg kunne læse din sætning
som at køre kode 'der' (remote server) og ikke 'her' (egen server).

Det var et forsøg på at præcisere risikoen for inficering på _egen_ server.

Gvis man opfatter det som at køre kode 'der', er der ikke den store risiko.

--
Med venlig hilsen
Stig Johansen

---

Den 21-02-2010 19:01, Stig Johansen skrev:

> I det her tilfælde ville jeg nok synes at det er nok at tjekke at input
> udelukkende består af a..z, 0..9 samt at bruge samme tegn til filnavne.

Netop efter din opskrift - men det er jo ikke sikkert sådan andre gør -
så har jeg delt mine sider op, så de altid har en default include helt
øverst, som gør følgende:

- Lav en 301 redirect5 til korrekt www eller non-www

- Tjek, at querystring karakterer er indenfor a-z, A-Z samt 0-9 og _ og
giv en 404, hvis overskrides (whitelist injection tjek, evil bot/hacker
1st level)

- Tjek, at ACCEPT_ENCODING indeholder GZIP ved method POST, ellers giv
en 404 (spambot, evil bot 2nd level)

- Tjek at user-agent ikke indeholder JAVA som det første uanset method,
i modsat fald giv 404 (harvestertjek, evil bot 3rd level)

- Generel validering af cookies efter samme mønster som querystring,
(evil bot/hacker - 4th level)

plus lidt mere - forme kan man ikke gøre det helt på samme måde som
querystring, det vil blive altfor snævert, men der er dog nogle
generelle ting her også.


>> Men det er en oplagt kandidat til databasen - der skal bare noget andet
>> sikring på $_GET...
>
> Yeps - brug parameterized queries, og du kan sove trygt og roligt udi al
> fremtid ;)
>
> (Desværre er det vist ikke så brugt i PHP verdenen, selvom 'vi' andre har
> brugt det i 15+ år).

Det var netop det, jeg tænkte på som 2nd level til databaser. Det er
bare ikke særlig mundret betegnelse "parameterized queries", så jeg
glemmer det hele tiden...

Forskellen er, hvor tjekkene ligger, og hvad de går efter. Generelle
initial tjeks, ligger altid først i dokumentkoden, så det man ved med
sikkerhed ikke er validt bliver skubbet ud så tidligt som muligt.


MVH
Rune Jensen

---

Den 21-02-2010 20:59, Rune Jensen skrev:

> - Tjek, at querystring karakterer er indenfor a-z, A-Z samt 0-9 og _ og
> giv en 404, hvis overskrides (whitelist injection tjek, evil bot/hacker
> 1st level)

Det skal siges, visse søgemaskiner har en tendens til at indsætte
spaces, som omdannes til %20, hvilket ikke er tilladt. For at få dem på
plads (de må gerne indeksere ikke-valide URLer/inbound links for min
skyld, sålænge jeg bare har kontrollen), så redirecter jeg i stedet til
initial URL (dvs. uden querystring) via en 301. Det gør jeg bl.a. på
webdesigngruppen.dk.

Det er en vurdering på søgemaskiner/brugervenlighed i forhold til, hvad
en evt. hacker-bot så vil gøre; Den kan jo se, der eksisterer en side,
hvorfor den måske kommer igen (og fylder Loggen), men den får ikke held
med sit forehavende via querystring.


MVH
Rune Jensen

---

Stig Johansen har bragt dette til os:
8X
>> Men det er en oplagt kandidat til databasen - der skal bare noget andet
>> sikring på $_GET...
>
> Yeps - brug parameterized queries, og du kan sove trygt og roligt udi al
> fremtid ;)
>
> (Desværre er det vist ikke så brugt i PHP verdenen, selvom 'vi' andre har
> brugt det i 15+ år).

Hvor finder man doc om parameterized queries i PHP?

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

> Hvor finder man doc om parameterized queries i PHP?

Det var vist MS udtrykket, PHP kalder det 'prepared statements'.
(Og Oracle kalder det vis parameter binding).

Jeg har ikke rodet syndeligt med PHP, men det afhænger vist også af hvike
client libraries, der er installeret hos udbyderen.

Noget med mysqli (hvis man bruger mySQL) eller PDO.

Sidstnævnte kunne godt ligne en pendant til ADO, som er _noget_ mere
fleksibel (og databaseuafhængig) at bruge.

--
Med venlig hilsen
Stig Johansen

---

> <div id="indhold">
> <?php
> $op = (string)$_GET['op'];
> $op = pathinfo( $op, PATHINFO_FILENAME).'.php';
> if ( file_exists( $op)) {
> include( $op);
> }
> else {
> echo "Prøv med en side der eksisterer - det er meget sjovere!<br>\n$op
> er ikke i min kogebog!";
> }
> ?>
> </div>

Tak for det, det virker bare.

Jeg havde ved en fejl, fået inkluderet en gammel opskrift, med

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="content-type"><title></title> osv. osv.

Så det stod midt på siden, når jeg valgte vis kilde.
Overraskede mig, at det alligevel virkede.

Mvh Edmund

---

Edmund formulerede spørgsmålet:
> Den 18-02-2010 14:15, Birger Sørensen skrev:
>
>> Hvor fik du den fra?
>> <!--#include file="menu.html"-->
>> er da vist SSI...
>
> Ja det er SSI, som jeg netop lige har afprøvet for første gang
>
> Jeg kender absolut intet til PHP og ASP.
>
> Mvh Edmund

Man skal jo begynde et sted
ASP og PHP (og andre af samme slags) er lidt det modsatte - men nyere
og mere tidssvarende, og med mange flere muligheder end SSI tilbyder.
SSI er scipts der indsættes i HTML, hvor PHP/ASP er scripts, der
generer HTML-koden.
Jeg er selv til PHP. Og hvis du er interesseret, er det bare at gå i
gang - der er masser af links til stof på nettet (google).
http://www.phpartikler.dk/index.php
er vist tidligere blevet nævnt her i grupperne, som et muligt sted at
begynde. Selv brugte jeg
http://www.php.net/manual/en/
i tidernes morgen.
Jeg vil nok anbefale, at du prøver noget andet end SSI. Ikke at jeg
tror SSI forsvinder, selvom det ikke er alle udbydere, der tilbyder det
længere. Men mulighederne er så meget større med serverside scripting
end med SSI.
Og det er ikke svært at komme i gang.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 18-02-2010 16:14, Birger Sørensen skrev:

> Og det er ikke svært at komme i gang.

Ok, tak, jeg vil kigge på det.

Det ligner basic/pascal fra gamle dage

Mvh Edmund

---

Den 18-02-2010 23:50, Edmund skrev:
> Den 18-02-2010 16:14, Birger Sørensen skrev:
>
>> Og det er ikke svært at komme i gang.
>
> Ok, tak, jeg vil kigge på det.
>
> Det ligner basic/pascal fra gamle dage

Hvis du har bare en anelse programmeringsbaggrund, er det en fordel, for
så er der nok nogle småting, som falder nemmere.

Nu har jeg selv programmeret i gammel BASIC til C64, og da dette til
forveksling ligner Visual Basic på visse punkter i syntaksen (det er
begge Microsoft-sprog), har jeg haft lettere ved at gå til VBscript end
til PHP, for VBscript er langt henad vejen også den samme syntaks som
Visual Basic (som jeg også har programmeret i).

Men egentlig er det bare at tage, hvad der falder nemmest - dog er PHP
nok mere nutidigt end VBscript, da VBscript ikke opdateres mere, så er
man ny til begge, er det nok bedst med PHP. Desuden er PHP lettere at
finde gratis scripts til end ASP/VBscript.


MVH
Rune Jensen

---

Efter mange tanker skrev Rune Jensen:
> Den 18-02-2010 23:50, Edmund skrev:
>> Den 18-02-2010 16:14, Birger Sørensen skrev:
>>
>>> Og det er ikke svært at komme i gang.
>>
>> Ok, tak, jeg vil kigge på det.
>>
>> Det ligner basic/pascal fra gamle dage
>
> Hvis du har bare en anelse programmeringsbaggrund, er det en fordel, for så
> er der nok nogle småting, som falder nemmere.
>
> Nu har jeg selv programmeret i gammel BASIC til C64, og da dette til
> forveksling ligner Visual Basic på visse punkter i syntaksen (det er begge
> Microsoft-sprog), har jeg haft lettere ved at gå til VBscript end til PHP,
> for VBscript er langt henad vejen også den samme syntaks som Visual Basic
> (som jeg også har programmeret i).
>
> Men egentlig er det bare at tage, hvad der falder nemmest - dog er PHP nok
> mere nutidigt end VBscript, da VBscript ikke opdateres mere, så er man ny til
> begge, er det nok bedst med PHP. Desuden er PHP lettere at finde gratis
> scripts til end ASP/VBscript.
>
>
> MVH
> Rune Jensen

Der er ikke ret stor forskel på syntaxen i javascript og PHP.
Men der er nu ret langt fra Basic og Pascal til PHP.

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Birger Sørensen wrote:

>> Hvis du bruger ASP, som noget tyder på, så prøv at spørge i
>> serverside.asp, så får du nok forslag til fremgangsmåde.
> 8X
>
> Hvor fik du den fra?
> <!--#include file="menu.html"-->
> er da vist SSI...

Syntaksen for inklude i asp er præcis den samme, så Runes formodning er slet
ikke så fejlplaceret.

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk

---

Den 19-02-2010 01:00, Erik Ginnerskov skrev:
> Birger Sørensen wrote:
>
>>> Hvis du bruger ASP, som noget tyder på, så prøv at spørge i
>>> serverside.asp, så får du nok forslag til fremgangsmåde.
>> 8X
>>
>> Hvor fik du den fra?
>> <!--#include file="menu.html"-->
>> er da vist SSI...
>
> Syntaksen for inklude i asp er præcis den samme, så Runes formodning er slet
> ikke så fejlplaceret.

Ja, det var egentlig det, jeg tog efter, men så kunne jeg jo se, at
Edmund bruger .shtml, så måtte det jo være SSI, ikke ASP.

;)

Iøvrigt, hvis nogen har anden forklaring end min på det med querystring,
må de gerne skrive. Jeg har en fornemmelse af, den er lidt knudret..


MVH
Rune Jensen

---

Rune Jensen wrote:

> Ja, det var egentlig det, jeg tog efter, men så kunne jeg jo se, at
> Edmund bruger .shtml, så måtte det jo være SSI, ikke ASP.

Det er først kommet frem senere.

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk

---

Den 19-02-2010 02:33, Erik Ginnerskov skrev:
> Rune Jensen wrote:
>
>> Ja, det var egentlig det, jeg tog efter, men så kunne jeg jo se, at
>> Edmund bruger .shtml, så måtte det jo være SSI, ikke ASP.
>
> Det er først kommet frem senere.

Ja, du har ret, en del senere.

Det må betyde, jeg er træt, så på tide at smutte i seng ;)


MVH
Rune Jensen

--

....he later signet a contract as Darth Vader in Star Wars,
because of his fighting skills with the lightsaber
http://www.youtube.com/watch?v=OG3PnQ3tgzY