---

Er lidt på herrerens mark, så jeg håber at I kan hjælpe med måske nogen
indlysende svar, som jeg dog ikke lige kan regne ud.

I min iver for at optimere mit web-site, så er jeg gået igang med at lave en
ny fil struktur på det dog driller det lidt. Bruger en menubar som bliver
kaldt ved hjælp af

<?
require("menubar.inc");
?>

Hidtil har menubar lagt i roden og i et par enkel biblioteker på sitet, men
jeg tænkte på om jeg kan lave noget, så menubaren kan nøjes med at lægge eet
central sted som alle under sider kan trække på, også selv om den lægge i
andre biblioteker end menubar.inc filen lægger, eller kan jeg hurtig se at
med det nye her jeg prøver at lave, så kommer menubar filen til at lægge
mange steder, hvilket jeg helt vil undgå.

Selvom der er både PHP og MySQL understøttelse på sitet, så har jeg lidt
svært ved at lære at udnytte mulighederne i det, så så enkle løsninger så
muligt er ønskeligt.

--
VH

Søren Blom
soren@blom.dk
Mail med spam filter besvares ikke.

---

Søren Blom wrote:
> Hidtil har menubar lagt i roden og i et par enkel biblioteker på sitet, men
> jeg tænkte på om jeg kan lave noget, så menubaren kan nøjes med at lægge eet
> central sted som alle under sider kan trække på, også selv om den lægge i

Du skal bare angive den "relative" sti til filerne. Dvs. ligger siden på
www.domæne.dk/mappe/side.php og du skal have fat i
www.domæne.dk/includes/menubar.php, skal din require() se sådan ud:

require("../includes/menubar.php")

De først to punktummer betyder "hop en mappe tilbage/op". "includes"
betyder at den skal kigge i mappen includes og menubar.php betyder ..
ja, du har nok fattet den. :)

Om der skulle være en bedere løsning, ved jeg ikke.

--
Anders Lund - anders@andersonline.dk

---

Anders Lund skrev:

>require("../includes/menubar.php")

Jeg vil foreslå:

   require("/includes/menubar.inc")

altså absolut placering. Så er der taget højde for at der måske
er forskel på hvilket mappeniveau den kaldende fil ligger i.

>Om der skulle være en bedere løsning, ved jeg ikke.

Det tror jeg ikke. Hvor meget enklere kan det være?

PS. Du havde brugt "php" som efternavn, men det skal vist være
"inc". Det er dog en detalje (og bestemmes af designeren).

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

On Fri, 20 Aug 2004 16:49:51 +0200, Bertel Lund Hansen wrote:

>
> PS. Du havde brugt "php" som efternavn, men det skal vist være "inc". Det
> er dog en detalje (og bestemmes af designeren).
Det er jeg nu ikke enig i Hvis man anvender php som efternavn, er man
sikret mod, at tilfældige personer kalder scriptet direkte, og dermed
får vist filens indhold. Endelsen php sikrer, at scriptet altid parses
gennem php-fortolkeren, hvorfor man vil få fremvist en tom side, hvis
includes ikke indeholder echo/print mm.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Q:   How many IBM CPU's does it take to do a logical right shift?
A:   33. 1 to hold the bits and 32 to push the register.

---

Michael Rasmussen skrev:
>>PS. Du havde brugt "php" som efternavn, men det skal vist være "inc". Det
>>er dog en detalje (og bestemmes af designeren).
>
> Det er jeg nu ikke enig i Hvis man anvender php som efternavn, er man
> sikret mod, at tilfældige personer kalder scriptet direkte, og dermed
> får vist filens indhold. Endelsen php sikrer, at scriptet altid parses
> gennem php-fortolkeren, hvorfor man vil få fremvist en tom side, hvis
> includes ikke indeholder echo/print mm.

- men man kan jo let sætte sin apache op til at parse php i .inc filer,
ligesom man i øvrigt også kan bede den om slet ikke at vise .inc-filers
indhold hvis de kaldes u-includet :)

mvh

Jesper Brunholm

---

"Jesper Brunholm" <nospam@brunholm-scharff.dk> wrote in message
news:41262746@news.wineasy.se...
> Michael Rasmussen skrev:
> >>PS. Du havde brugt "php" som efternavn, men det skal vist være "inc".
Det
> >>er dog en detalje (og bestemmes af designeren).
> >
> > Det er jeg nu ikke enig i Hvis man anvender php som efternavn, er man
> > sikret mod, at tilfældige personer kalder scriptet direkte, og dermed
> > får vist filens indhold. Endelsen php sikrer, at scriptet altid parses
> > gennem php-fortolkeren, hvorfor man vil få fremvist en tom side, hvis
> > includes ikke indeholder echo/print mm.
>
> - men man kan jo let sætte sin apache op til at parse php i .inc filer,
> ligesom man i øvrigt også kan bede den om slet ikke at vise .inc-filers
> indhold hvis de kaldes u-includet :)

Ja, men du er 100% sikret mod uaftoriseret læsning hvis du kalder dem .php
Det er klart at foretrække fremfor .inc!

Mvh
Jimmy

---

Jimmy wrote:

>>- men man kan jo let sætte sin apache op til at parse php i .inc filer,
>
> Ja, men du er 100% sikret mod uaftoriseret læsning hvis du kalder dem .php

Hvis du har sat din server op til at parse .inc filer, som var de PHP,
så giver det nøjagtig det samme.

> Det er klart at foretrække fremfor .inc!

Hvis serveren behandler filerne ens, så er det lige meget.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:41262f0b$0$207$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> >>- men man kan jo let sætte sin apache op til at parse php i .inc filer,
> >
> > Ja, men du er 100% sikret mod uaftoriseret læsning hvis du kalder dem
..php
>
> Hvis du har sat din server op til at parse .inc filer, som var de PHP,
> så giver det nøjagtig det samme.

Ja. Kodeordet er "Hvis".
Det er det "hvis" jeg ikke behøver at tænke på når man anvender .php.


> > Det er klart at foretrække fremfor .inc!
>
> Hvis serveren behandler filerne ens, så er det lige meget.

Der er dit "hvis" igen.

Mvh
Jimmy

---

Jimmy wrote:

> Ja. Kodeordet er "Hvis".
> Det er det "hvis" jeg ikke behøver at tænke på når man anvender .php.

Forskellen ligger i hvad vi taler om. Jeg taler om hvad man kan gøre på
min server - du taler om hvad man kan gøre på andres servere.

Og HVIS man nu kræver at det kører PHP 5 og PHP 5 filerne kun bliver
parset som PHP5, hvis de hedder .php5 .. hvor står vi så.

Men sådan kan vi blive ved og vi har begge ret - vi ser det bare fra 2
forskellige vinkler.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:412651c4$0$212$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Ja. Kodeordet er "Hvis".
> > Det er det "hvis" jeg ikke behøver at tænke på når man anvender .php.
>
> Forskellen ligger i hvad vi taler om. Jeg taler om hvad man kan gøre på
> min server - du taler om hvad man kan gøre på andres servere.

Både og. Jeg taler om hvad der giver størst sandsynlighed for at
uaftoriseret adgang begrænses.
Alt andet lige giver .php en større sikkerhed end .inc over et gennemsnit af
delte og dedikerede maskiner. Derfor hævder jeg at det er den mest
hensigtsmæssige endelse.
Det gør koden mere porterbar mens kode med .inc endelser ikke er porterbar i
samme grad, hvis man ønsker høj sikkerhed.


> Og HVIS man nu kræver at det kører PHP 5 og PHP 5 filerne kun bliver
> parset som PHP5, hvis de hedder .php5 .. hvor står vi så.

Hypoteser er uinteressante i denne sammenhæng.

Mvh
Jimmy

---

Jimmy wrote:

> Alt andet lige giver .php en større sikkerhed end .inc over et gennemsnit af
> delte og dedikerede maskiner. Derfor hævder jeg at det er den mest
> hensigtsmæssige endelse.

Nej, du siger at det er 100% sikkeret at bruge .php som endelse. Det er
det ikke, men kan været det i de fleste tilfælde, hvis serveren forstår PHP.

Ja ja... Hvis og hvis.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:41266bb7$0$213$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Alt andet lige giver .php en større sikkerhed end .inc over et
gennemsnit af
> > delte og dedikerede maskiner. Derfor hævder jeg at det er den mest
> > hensigtsmæssige endelse.
>
> Nej, du siger at det er 100% sikkeret at bruge .php som endelse. Det er
> det ikke, men kan været det i de fleste tilfælde, hvis serveren forstår
PHP.

Vi er i PHP-gruppen. Tro mig - Serveren forstår PHP.

/Jimmy

---

Jimmy wrote:

>>Nej, du siger at det er 100% sikkeret at bruge .php som endelse. Det er
>>det ikke, men kan været det i de fleste tilfælde, hvis serveren forstår
>>PHP.
>
> Vi er i PHP-gruppen. Tro mig - Serveren forstår PHP.

Ja, men derfor er det stadig ikke 100% sikkert at filerne skal hedde
..php. Det er et spørgsmål om opsætning.

Personligt synes jeg at vi er ude i nogle detaljer, som ikke er
interresante at diskutere.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:4126fe8d$0$212$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> >>Nej, du siger at det er 100% sikkeret at bruge .php som endelse. Det er
> >>det ikke, men kan været det i de fleste tilfælde, hvis serveren forstår
> >>PHP.
> >
> > Vi er i PHP-gruppen. Tro mig - Serveren forstår PHP.
>
> Ja, men derfor er det stadig ikke 100% sikkert at filerne skal hedde
> .php. Det er et spørgsmål om opsætning.
>
> Personligt synes jeg at vi er ude i nogle detaljer, som ikke er
> interresante at diskutere.

Det er som man tager det.
Jeg påstår blot at det er mere sikkert at kalde dem .php end .inc. Du siger
at .inc er fint, men tager så en masse forbehold.

Det korte af det lange er jo at .php er mere sikkert og porterbart.

Det behøver vi nok ikke at diskuttere længere.

Mvh
Jimmy

---

Jimmy wrote:

> Jeg påstår blot at det er mere sikkert at kalde dem .php end .inc. Du siger
> at .inc er fint, men tager så en masse forbehold.

Ét forbehold - at servere parser .inc filer som PHP filer.

> Det korte af det lange er jo at .php er mere sikkert og porterbart.

Se, det er der forskellen ligger. Det er ikke mere sikkert. Det er mere
sikkert HVIS det skal porteres. Sikkerheden er den samme, så længe .inc
filer bliver parset som PHP filer.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:412707ef$0$206$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Jeg påstår blot at det er mere sikkert at kalde dem .php end .inc. Du
siger
> > at .inc er fint, men tager så en masse forbehold.
>
> Ét forbehold - at servere parser .inc filer som PHP filer.

Ja, men det gør de ikke som udgangspunkt og det er dér dit problem opstår.
Det er derfor mere sikkert at kalde dem .php
Det parses uden forbehold.


> > Det korte af det lange er jo at .php er mere sikkert og porterbart.
>
> Se, det er der forskellen ligger. Det er ikke mere sikkert. Det er mere
> sikkert HVIS det skal porteres. Sikkerheden er den samme, så længe .inc
> filer bliver parset som PHP filer.

Dit forbehold holder ikke, når det ikke er standardopførsel af .inc parses.

Du forudsætter en viden, som begynder ikke kan forventes at have samt at man
overhovedet har mulighed for at ændre på serverens opsætning.

Kort sagt - Det er mere sikkert at kalde dem .php end .inc
Jeg vil gå så vidt som at sige at det er ekstremt usikkert at kalde dem .inc
da langt størstedelen af alle servere IKKE er sat op til at parse .inc

Hvis filerne skal flyttes til en anden server kan du ikke forvente at den
der flytter filerne er opmærksom på at du har valgt at lægge brugernavn og
adgangskoder i en .inc fil og at disse nu eksponeres når de flytter filerne
over på en anden server.

Bare det at du overhovedet *har* et forbehold burde få dig til at indse, at
..php er bedre end dit .inc
Hvis du kunne fjerne dit forbehold ville du være nået langt. Det kan du så
kun med .php

Mvh
Jimmy

---

Jimmy wrote in dk.edb.internet.webdesign.serverside.php:
> "Anders Lund" <anders@andersonline.dk> wrote in message
> news:412707ef$0$206$14726298@news.sunsite.dk...
> > Jimmy wrote:
> >
> > > Jeg påstår blot at det er mere sikkert at kalde dem .php end .inc. Du
> siger
> > > at .inc er fint, men tager så en masse forbehold.
> >
> > Ét forbehold - at servere parser .inc filer som PHP filer.
>
> Ja, men det gør de ikke som udgangspunkt og det er dér dit problem opstår.
> Det er derfor mere sikkert at kalde dem .php
> Det parses uden forbehold.
>
>
> > > Det korte af det lange er jo at .php er mere sikkert og porterbart.
> >
> > Se, det er der forskellen ligger. Det er ikke mere sikkert. Det er mere
> > sikkert HVIS det skal porteres. Sikkerheden er den samme, så længe .inc
> > filer bliver parset som PHP filer.
>
> Dit forbehold holder ikke, når det ikke er standardopførsel af .inc parses.
>
> Du forudsætter en viden, som begynder ikke kan forventes at have samt at man
> overhovedet har mulighed for at ændre på serverens opsætning.
>
> Kort sagt - Det er mere sikkert at kalde dem .php end .inc
> Jeg vil gå så vidt som at sige at det er ekstremt usikkert at kalde dem .inc
> da langt størstedelen af alle servere IKKE er sat op til at parse .inc
>
> Hvis filerne skal flyttes til en anden server kan du ikke forvente at den
> der flytter filerne er opmærksom på at du har valgt at lægge brugernavn og
> adgangskoder i en .inc fil og at disse nu eksponeres når de flytter filerne
> over på en anden server.
>
> Bare det at du overhovedet *har* et forbehold burde få dig til at indse, at
> ..php er bedre end dit .inc
> Hvis du kunne fjerne dit forbehold ville du være nået langt. Det kan du så
> kun med .php
>
Det kommer da an på om han kører egen server, så kan han for den sags skyld
kalde sine filer .anders hvor det stadig er lige så sikkert som .php. Det er jo
bare opsætningen af server. Ligesom nogle servere er sat op til det hedder
phtml eller som webcafe.dk bare .html selvom det er php filer.

--
Vil du lære at kode HTML, XHTML, CSS, SSI eller ASP?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

"Christian Hjort" <SphinX@mail-online.dk> wrote in message
news:41271a9e$0$205$14726298@news.sunsite.dk...

> Det kommer da an på om han kører egen server, så kan han for den sags
skyld
> kalde sine filer .anders hvor det stadig er lige så sikkert som .php. Det
er jo
> bare opsætningen af server. Ligesom nogle servere er sat op til det hedder
> phtml eller som webcafe.dk bare .html selvom det er php filer.

Kan du lokkes til at læse de tidligere indlæg?

/Jimmy

---

Jimmy wrote:

> Kan du lokkes til at læse de tidligere indlæg?

Hmm, jeg har lige læst dem igennem og min mening er den som Christian
har skrevet. Jeg kører min egen server og har tingene sat op på min måde.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:41279a59$0$216$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Kan du lokkes til at læse de tidligere indlæg?
>
> Hmm, jeg har lige læst dem igennem og min mening er den som Christian
> har skrevet.

Ja, men Christian gentog blot, hvad der var sagt 100 gange. Det var ikke
dig, der skulle læse dem igen


> Jeg kører min egen server og har tingene sat op på min måde.

Fint, men det er altså ikke anbefalelsesværdigt at opfordre andre til at
bruge .inc.

Mvh
Jimmy

---

Jimmy wrote:

> Dit forbehold holder ikke, når det ikke er standardopførsel af .inc parses.

Jeg er lige glad med andre - jeg skal kører mine applicationer på min
server, sådan som jeg vil kører dem.

> Du forudsætter en viden, som begynder ikke kan forventes at have samt at man
> overhovedet har mulighed for at ændre på serverens opsætning.

Igen - dette er jeg lige glad med. Jeg kan sætte min server op sådan som
jeg vil have det og kan derefter bruge den på den måde jeg vil have det.

> Kort sagt - Det er mere sikkert at kalde dem .php end .inc

Ja, hvis man skal flytte dem imellem flere servere. Det skal jeg ikke og
derfor får jeg den samme sikkerhed.

> Jeg vil gå så vidt som at sige at det er ekstremt usikkert at kalde dem .inc
> da langt størstedelen af alle servere IKKE er sat op til at parse .inc

Servere kan sættes forskelligt op - jeg sætter min server op på den måde
jeg kan lide det og laver mine ting herefter.

> Hvis filerne skal flyttes til en anden server kan du ikke forvente at den
> der flytter filerne er opmærksom på at du har valgt at lægge brugernavn og
> adgangskoder i en .inc fil og at disse nu eksponeres når de flytter filerne
> over på en anden server.

Jeg ville nu kontrollere flere ting. Men for "almindelige brugere" kan
det være en fordel at kalde det .php. Jeg er ligeglad, for jeg laver mit
program som jeg vil have det.

Desuden ville mine applicationer slet ikke kunne læse indholdet af den
type filer jeg laver, hvis de ikke bliver fortolket som PHP - og derfor
med det samme afslører om den parser .inc filerne.

> Bare det at du overhovedet *har* et forbehold burde få dig til at indse, at
> .php er bedre end dit .inc

Hvis det er nemmere for mig at kalde det for .inc i stedet for .php og
jeg bare retter min server opsætning, så er det faktisk bedere på min
måde. Når jeg alligevel opsætter min næste Apache server, skal jeg
fortælle min server at den skal parse .php filer, så får den også afvide
at den skal parse .inc filer.

> Hvis du kunne fjerne dit forbehold ville du være nået langt. Det kan du så
> kun med .php

Det giver den samme sikkerhed for mig. Det er en kopy/paste operation
ekstra i opsætningen og hvis den ikker er til stede, virker mine sider ikke.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:412798e9$0$208$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Dit forbehold holder ikke, når det ikke er standardopførsel af .inc
parses.
>
> Jeg er lige glad med andre - jeg skal kører mine applicationer på min
> server, sådan som jeg vil kører dem.

Det har jeg fanget, men det er jo ikke din specifikke opsætning diskussionen
går på.
Den går på, hvad der er mest sikkert i et gennemsnit for den almindelige
bruger.


> > Du forudsætter en viden, som begynder ikke kan forventes at have samt at
man
> > overhovedet har mulighed for at ændre på serverens opsætning.
>
> Igen - dette er jeg lige glad med. Jeg kan sætte min server op sådan som
> jeg vil have det og kan derefter bruge den på den måde jeg vil have det.

Ja DU gør, men det kan andre ikke og andre besidder ikke den viden du har,
hvorfor det er en skidt ide at kalde filerne for .inc.


> > Kort sagt - Det er mere sikkert at kalde dem .php end .inc
>
> Ja, hvis man skal flytte dem imellem flere servere. Det skal jeg ikke og
> derfor får jeg den samme sikkerhed.

Nu taler vi jo stadig ikke om dig, men om andre.


> > Jeg vil gå så vidt som at sige at det er ekstremt usikkert at kalde dem
..inc
> > da langt størstedelen af alle servere IKKE er sat op til at parse .inc
>
> Servere kan sættes forskelligt op - jeg sætter min server op på den måde
> jeg kan lide det og laver mine ting herefter.

Det er ikke dig specifikt vi taler om. Vi taler på et generelt plan.


> > Hvis filerne skal flyttes til en anden server kan du ikke forvente at
den
> > der flytter filerne er opmærksom på at du har valgt at lægge brugernavn
og
> > adgangskoder i en .inc fil og at disse nu eksponeres når de flytter
filerne
> > over på en anden server.
>
> Jeg ville nu kontrollere flere ting. Men for "almindelige brugere" kan
> det være en fordel at kalde det .php. Jeg er ligeglad, for jeg laver mit
> program som jeg vil have det.

Når vi tager udgangspunkt i at du er uinteressant i denne diskussion ser det
ud til at vi er enige.
Det holdt hårdt


> > Hvis du kunne fjerne dit forbehold ville du være nået langt. Det kan du
så
> > kun med .php
>
> Det giver den samme sikkerhed for mig.

Så er det jo godt at vi ikke taler om dig, men om den generelle bruger,
Phew.

Mvh
Jimmy

---

Jimmy wrote:

> Det har jeg fanget, men det er jo ikke din specifikke opsætning diskussionen
> går på.
> Den går på, hvad der er mest sikkert i et gennemsnit for den almindelige
> bruger.

Nej, den startede med at der blev sagt at det var mere sikkert at kalde
filerne .php end .inc. Det blev så senere drejet over på hvad
"almindelige brugere" gør.

> Når vi tager udgangspunkt i at du er uinteressant i denne diskussion ser det
> ud til at vi er enige.

Ja, jeg har hele tiden kunne se det fra din vinkel af. Jeg er bare uenig
i at korte det ned til ".php er mere sikkert end .inc", når det ikke
altid gælder.

> Så er det jo godt at vi ikke taler om dig, men om den generelle bruger,
> Phew.

Ja, det blev det jo til.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:4127ac1a$0$209$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Det har jeg fanget, men det er jo ikke din specifikke opsætning
diskussionen
> > går på.
> > Den går på, hvad der er mest sikkert i et gennemsnit for den almindelige
> > bruger.
>
> Nej, den startede med at der blev sagt at det var mere sikkert at kalde
> filerne .php end .inc.


Ja - Vil du da påstå at det er mere usikkert at kalde dem for .php?
Eller at .inc er mere sikkert?

Bemærk at der ikke skal tages nogen forbehold for at vi taler om dig og din
server.


> Det blev så senere drejet over på hvad
> "almindelige brugere" gør.

Jeg kan ikke se hvad det ellers skulle dreje sig om.


> > Når vi tager udgangspunkt i at du er uinteressant i denne diskussion ser
det
> > ud til at vi er enige.
>
> Ja, jeg har hele tiden kunne se det fra din vinkel af. Jeg er bare uenig
> i at korte det ned til ".php er mere sikkert end .inc", når det ikke
> altid gælder.

Men det gælder næsten altid er .inc er mere usikkert, og det forsvarer du?

Det hænger altså ikke sammen.

/Jimmy

---

Jimmy wrote:

>>Nej, den startede med at der blev sagt at det var mere sikkert at kalde
>>filerne .php end .inc.
>
> Ja - Vil du da påstå at det er mere usikkert at kalde dem for .php?
> Eller at .inc er mere sikkert?

Nej, jeg vil heller ikke påstå at det er direkte det modsatte der gælder.

> Bemærk at der ikke skal tages nogen forbehold for at vi taler om dig og din
> server.

Alle servere kan sættes op på samme måde.

> Jeg kan ikke se hvad det ellers skulle dreje sig om.

Noget så basalt som at man kan få .inc filer til at opfører sig på samme
måde som .php.

> Men det gælder næsten altid er .inc er mere usikkert, og det forsvarer du?

Det handler jo slet ikke om at forsvare noget som helst. Du siger at
..inc filer er mere usikkert. Ja det er det, hvis serveren ikke er sat op
til at parse .inc filer.

Forskellen ligger i at du prøver at sikre flest mulige, ud fra hvad man
typisk vil sætte en server op til. Jeg prøver at forklare at man godt
kan have den samme sikkerhed, ved korrekt opsætning af serveren.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:4127b563$0$215$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> >>Nej, den startede med at der blev sagt at det var mere sikkert at kalde
> >>filerne .php end .inc.
> >
> > Ja - Vil du da påstå at det er mere usikkert at kalde dem for .php?
> > Eller at .inc er mere sikkert?
>
> Nej, jeg vil heller ikke påstå at det er direkte det modsatte der gælder.

Se det var et præcist svar


> > Bemærk at der ikke skal tages nogen forbehold for at vi taler om dig og
din
> > server.
>
> Alle servere kan sættes op på samme måde.

Ja - Igen tager du forbehold. Jeg taler om den størst mulige sikkerhed.
Jeg skal gerne gentage at det er DEFAULT at .inc IKKE parses og at kalde
filerne for .php vil derfor give størstedelen af alle brugere en større
sikkerhed.


> > Jeg kan ikke se hvad det ellers skulle dreje sig om.
>
> Noget så basalt som at man kan få .inc filer til at opfører sig på samme
> måde som .php.

Når det er det du har diskutteret har du ikke læst mine indlæg korrekt, for
jeg har aldrig modsat at man *kan*.


> > Men det gælder næsten altid er .inc er mere usikkert, og det forsvarer
du?
>
> Det handler jo slet ikke om at forsvare noget som helst. Du siger at
> .inc filer er mere usikkert. Ja det er det, hvis serveren ikke er sat op
> til at parse .inc filer.

Godt - Det er langt de fleste servere ikke da det ikke er default at de
skal.
Sjovt du danser udenom for i bund og grund er vi jo enige.
Jeg er fortsat 110% ligeglad med din server og hvordan servere *kan* sættes
op. Jeg taler fortsat på et generelt plan.


> Forskellen ligger i at du prøver at sikre flest mulige, ud fra hvad man
> typisk vil sætte en server op til.

Hey - Du har fanget min pointe.


> Jeg prøver at forklare at man godt
> kan have den samme sikkerhed, ved korrekt opsætning af serveren.

Ja da - Har du læst mine indlæg som om at jeg mente man ikke kunne?

Mvh
Jimmy

---

Jimmy wrote:

> Ja - Igen tager du forbehold. Jeg taler om den størst mulige sikkerhed.
> Jeg skal gerne gentage at det er DEFAULT at .inc IKKE parses og at kalde
> filerne for .php vil derfor give størstedelen af alle brugere en større
> sikkerhed.

Og jeg har hele tiden snakket om hvad man kan og ikke hvad den
gennerelle opsætning af servere er.

> Når det er det du har diskutteret har du ikke læst mine indlæg korrekt, for
> jeg har aldrig modsat at man *kan*.

Og du har ikke læst mine korrekt.

> Godt - Det er langt de fleste servere ikke da det ikke er default at de
> skal.

Min Apache server - og mange andre er som default slet ikke sat op til
at parse .php filer. :)

> Sjovt du danser udenom for i bund og grund er vi jo enige.

Og jeg kan sige det samme om dig.

> Jeg er fortsat 110% ligeglad med din server og hvordan servere *kan* sættes
> op. Jeg taler fortsat på et generelt plan.

Og jeg er 110% ligeglad med det gennerelle plan og er mere interreseret
i hvad man teknisk kan.

> Ja da - Har du læst mine indlæg som om at jeg mente man ikke kunne?

Spørgsmålet er bare om du har læst mine. Lige så meget som du er
ligeglad med min server er jeg ligeglad med hvordan andre sætter deres
servere på.

Det jeg i mit "første" indlæg skrev var en "protest". Vil du ikke give
mig ret i at hvis man sætter en server op til at parse .inc som PHP
filer, så er de lige så sikre som .php filer? Og her tales der om hvad
der er teknisk muligt og ikke hvad webservere normalt er sat op til.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:4127c3ba$0$215$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Ja - Igen tager du forbehold. Jeg taler om den størst mulige sikkerhed.
> > Jeg skal gerne gentage at det er DEFAULT at .inc IKKE parses og at kalde
> > filerne for .php vil derfor give størstedelen af alle brugere en større
> > sikkerhed.
>
> Og jeg har hele tiden snakket om hvad man kan og ikke hvad den
> gennerelle opsætning af servere er.


Nå, jamen det er da ret uinteressant når min påstand er, at det er sikrere
at kalde dem for .php set med statistiske øjne.



> > Sjovt du danser udenom for i bund og grund er vi jo enige.
>
> Og jeg kan sige det samme om dig.

Det må du gerne, men jeg er ikke enig. Jeg har hele tiden forsøgt at
forklare hvad jeg taler om, men du har ikke rigtigt ville lytte til det.
Jeg har forstået hvad du taler om og har mange gange gjort klart at det var
det emne jeg jeg satte og du anfægtede.


> > Jeg er fortsat 110% ligeglad med din server og hvordan servere *kan*
sættes
> > op. Jeg taler fortsat på et generelt plan.
>
> Og jeg er 110% ligeglad med det gennerelle plan og er mere interreseret
> i hvad man teknisk kan.

Det er fint du er interesseret i det, men det var altså ikke det jeg talte
om, og som du anfægtede.


> Det jeg i mit "første" indlæg skrev var en "protest". Vil du ikke give
> mig ret i at hvis man sætter en server op til at parse .inc som PHP
> filer, så er de lige så sikre som .php filer? Og her tales der om hvad
> der er teknisk muligt og ikke hvad webservere normalt er sat op til.

Jo - HVIS - man gør det så er det lige så sikkert.
Men da det IKKE er default er det en uendeligt skidt praksis at anbefale.

Du har en påstand, som er hængt op på et forbehold man ikke kan forvente er
taget. Min påstand lider ikke af samme problem.

Mvh
Jimmy

---

Jimmy wrote:

> Nå, jamen det er da ret uinteressant når min påstand er, at det er sikrere
> at kalde dem for .php set med statistiske øjne.

Jeg har blot sagt at man sagtens kan sætte en webserver op, så det er
lige sikkert.

> Det må du gerne, men jeg er ikke enig. Jeg har hele tiden forsøgt at
> forklare hvad jeg taler om, men du har ikke rigtigt ville lytte til det.

Jeg har lyttet og jeg har givet dig ret, hvis man er en almindelig
bruger som skal flytte data og man ikke har adgang til konfiguration af
sit webhotel.

> Jeg har forstået hvad du taler om og har mange gange gjort klart at det var
> det emne jeg jeg satte og du anfægtede.

Det kan vi vist blive ved med det her. Jeg skrev i mit første indlæg at
det var teknisk muligt at gøre det lige så sikkert. Og det er stadig det
jeg prøver at sige. Jeg ved godt at det vil være mere sikkert for de
fleste mennekser, men det er uinterresandt, da mit første indlæg gik på
teknikken for at gøre det lige så sikkert.

> Jo - HVIS - man gør det så er det lige så sikkert.
> Men da det IKKE er default er det en uendeligt skidt praksis at anbefale.

Jeg skriver igen heller ikke om hvad folk skal gøre. Jeg skriver hvad
man kan gøre.

> Du har en påstand, som er hængt op på et forbehold man ikke kan forvente er
> taget. Min påstand lider ikke af samme problem.

Min påstand lider heller ikke er noget specielt problem. Her er hvad jeg
skriver i min config fil til min Apache:

ScriptAlias /php/ "c:/php/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"

Med tilføjelse af ".inc" bagefter ".php", som jeg faktisk ikke ved er
rigtigt da jeg ikke har brugt det og faktisk kalder de filer jeg
includer for .php, får jeg samme funktinalitet.

Skulle jeg (og andre) gå hen og kalde deres include filer for .inc og de
ikke lavede overstående rettelse, ville deres hjemmesider sikkert ikke
virke.

Bare for at slå det fast en gang til og gøre det så simpelt som muligt:

Du har ret i at det for flertallet vil være mere sikkert at kalde deres
include filer for .php.

Jeg har ret i at man teknisk kan gøre det lige så sikkert med .inc filer.

--
Anders Lund - anders@andersonline.dk

---

"Anders Lund" <anders@andersonline.dk> wrote in message
news:4128804c$0$205$14726298@news.sunsite.dk...
> Jimmy wrote:
>
> > Nå, jamen det er da ret uinteressant når min påstand er, at det er
sikrere
> > at kalde dem for .php set med statistiske øjne.
>
> Jeg har blot sagt at man sagtens kan sætte en webserver op, så det er
> lige sikkert.

Og det har jeg heller aldrig sagt dig imod. .php er på størstedelen af
verdens Apache-servere bare mere sikkert.


> > Du har en påstand, som er hængt op på et forbehold man ikke kan forvente
er
> > taget. Min påstand lider ikke af samme problem.
>
> Min påstand lider heller ikke er noget specielt problem.

Jo, den lider under at det ikke er default.
Og det er et reelt problem, hvis man skal sammenligne de to endelser.


> Bare for at slå det fast en gang til og gøre det så simpelt som muligt:
>
> Du har ret i at det for flertallet vil være mere sikkert at kalde deres
> include filer for .php.

Jeps.


> Jeg har ret i at man teknisk kan gøre det lige så sikkert med .inc filer.

Interessant du siger at du har ret i det, for det har jeg aldrig nogensinde
anfægtet det korrekte i.

Hav nu en god søndag,
Jimmy

---

Jimmy wrote:

> Interessant du siger at du har ret i det, for det har jeg aldrig nogensinde
> anfægtet det korrekte i.

Det var blot for at give os begge ret.

> Hav nu en god søndag,

Tak - ditto. :)

--
Anders Lund - anders@andersonline.dk

---

I news:41262df9$0$214$14726298@news.sunsite.dk skrev
Jimmy følgende:

>> - men man kan jo let sætte sin apache op til at parse php i .inc
>> filer, ligesom man i øvrigt også kan bede den om slet ikke at vise
>> .inc-filers indhold hvis de kaldes u-includet :)
>
> Ja, men du er 100% sikret mod uaftoriseret læsning hvis du kalder
> dem .php Det er klart at foretrække fremfor .inc!

Og så er det jo heller ikke alle der kører med en apache-server

--
Med venlig hilsen Andreas Falck - ICQ 108 480 093
http://maranatha.dk/ + http://skabelsen.info/
http://ravsted.dk/ - *Byen hvor der virkelig sker noget*
http://ravsted.net/ - *Lokalhistoriske sider*

---

"Andreas Falck" <fake@skrift.dk.invalid> wrote in message
news:41262f5c$0$177$edfadb0f@dtext02.news.tele.dk...
> I news:41262df9$0$214$14726298@news.sunsite.dk skrev
> Jimmy følgende:
>
> >> - men man kan jo let sætte sin apache op til at parse php i .inc
> >> filer, ligesom man i øvrigt også kan bede den om slet ikke at vise
> >> .inc-filers indhold hvis de kaldes u-includet :)
> >
> > Ja, men du er 100% sikret mod uaftoriseret læsning hvis du kalder
> > dem .php Det er klart at foretrække fremfor .inc!
>
> Og så er det jo heller ikke alle der kører med en apache-server

Platformen er da underordnet når vi taler om .inc/.php-problematikken.

Mvh
Jimmy

---

I news:412633ca$0$216$14726298@news.sunsite.dk skrev
Jimmy følgende:

>>>> - men man kan jo let sætte sin apache op til at parse php i .inc
>>>> filer, ligesom man i øvrigt også kan bede den om slet ikke at
>>>> vise .inc-filers indhold hvis de kaldes u-includet :)
>>>
>>> Ja, men du er 100% sikret mod uaftoriseret læsning hvis du kalder
>>> dem .php Det er klart at foretrække fremfor .inc!
>>
>> Og så er det jo heller ikke alle der kører med en apache-server
>
> Platformen er da underordnet når vi taler om
> .inc/.php-problematikken.

Hvis du ser på hvad jeg citerede, var mit svar et suplerende svar til
dit svar på det øverste i citatet.

Jesper Brunholms forslag har kun interesse såfremt der køres med en
apache-server, dit svar kan nemlig bruges uanset platform.

Jeg har i en anden tråd fået fin vejledning hvordan man kan sikre sig
bedst muligt ved at kalde sine include-filer for xxxxx.inc.php og have
lidt ekstra kode. Jeg fik foreslået dette:

<-- citat start -->
<?php
$body = $_REQUEST['body'];
switch($body) {
case 'adminside':
$include = "admin/opret1.inc.php";
break;

case 'nyheder':
$include = "nyheder.inc.php";
break;

default:
$include = "";
}

if ($include != "") {
include($include);
}

?>
<-- citat slut -->

Og det ser ud til at virke rigtig godt.

--
Med venlig hilsen Andreas Falck - ICQ 108 480 093
http://maranatha.dk/ + http://skabelsen.info/
http://bibeltro.dk/ + http://bibel-skole.dk/
http://ravsted.dk/ - *Byen hvor der virkelig sker noget*

---

"Andreas Falck" <fake@skrift.dk.invalid> wrote in message
news:412675c6$0$182$edfadb0f@dtext02.news.tele.dk...
> I news:412633ca$0$216$14726298@news.sunsite.dk skrev
> Jimmy følgende:
>
> >>>> - men man kan jo let sætte sin apache op til at parse php i .inc
> >>>> filer, ligesom man i øvrigt også kan bede den om slet ikke at
> >>>> vise .inc-filers indhold hvis de kaldes u-includet :)
> >>>
> >>> Ja, men du er 100% sikret mod uaftoriseret læsning hvis du kalder
> >>> dem .php Det er klart at foretrække fremfor .inc!
> >>
> >> Og så er det jo heller ikke alle der kører med en apache-server
> >
> > Platformen er da underordnet når vi taler om
> > .inc/.php-problematikken.
>
> Hvis du ser på hvad jeg citerede, var mit svar et suplerende svar til
> dit svar på det øverste i citatet.
>
> Jesper Brunholms forslag har kun interesse såfremt der køres med en
> apache-server, dit svar kan nemlig bruges uanset platform.

Det kan Jespers svar da også. IIS kan sagtens parse .inc filer som enten asp
eller php.
Jeg er ikke med.


> Jeg har i en anden tråd fået fin vejledning hvordan man kan sikre sig
> bedst muligt ved at kalde sine include-filer for xxxxx.inc.php og have
> lidt ekstra kode. Jeg fik foreslået dette:

Det virker også fint, men hvorfor skulle det give ekstra sikring? .php i sig
selv er jo tilstrækkeligt.

Mvh
Jimmy

---

On Fri, 20 Aug 2004 18:31:02 +0200, Jesper Brunholm wrote:

>
> - men man kan jo let sætte sin apache op til at parse php i .inc filer,
> ligesom man i øvrigt også kan bede den om slet ikke at vise .inc-filers
> indhold hvis de kaldes u-includet :)
>
Jeg kender ingen webhoteller, hvor de tillader brugerne at ændre i
apache, iis etc. opsætning. Gør du?

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plaugher)

---

Michael Rasmussen skrev:
>>- men man kan jo let sætte sin apache op til at parse php i .inc filer,
>>ligesom man i øvrigt også kan bede den om slet ikke at vise .inc-filers
>>indhold hvis de kaldes u-includet :)
>>
>
> Jeg kender ingen webhoteller, hvor de tillader brugerne at ændre i
> apache, iis etc. opsætning. Gør du?

Jeg talte ud fra et generelt synspunkt om hvilken filendelse der er
sikrest, og fremlagde så synspunktet, at hvis man kalder includefiler
noget andet end direkte viste filer så kan man sætte serveren op til aldrig
at vise indholdet af direkte viste includefiler.

Jeg arbejder på en server hvor det er gjort aht. sikkerheden, og jeg
synes egentlig det er smart.

Jeg tog ikke stilling til om man kan gøre det på dette eller hint
webhotel. Jeg kender til webhotelløsninger hvor man kan gå ændret i
apacheopsætningen, men de er dyre - ja.

Men der er jo også folk herinde som også arbejder på serverens
opsætning, så jeg synes da ikke min betragtning var decideret
irellevant?


mvh

Jesper Brunholm

---

Michael Rasmussen skrev:

>> PS. Du havde brugt "php" som efternavn, men det skal vist være "inc". Det
>> er dog en detalje (og bestemmes af designeren).

>Det er jeg nu ikke enig i

Spørgeren har kaldt sin fil "menubar.inc".

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:
>    require("/includes/menubar.inc")

Ah, ja. Det er fordi jeg har brugt det til at komme "uden for" web-root,
for at få fat i nogle filer, som brugeren ikke måtte kunne få fat i. :)

Kan det gøres på anden måde? "/../hemligmappe/fil.jpg" ?

--
Anders Lund - anders@andersonline.dk

---

Anders Lund skrev:

>Ah, ja. Det er fordi jeg har brugt det til at komme "uden for" web-root,
>for at få fat i nogle filer, som brugeren ikke måtte kunne få fat i. :)

Det kan man vist ikke på et normalt webhotel eller en almindelig
hjemmeside hos en udbyder.

>Kan det gøres på anden måde? "/../hemligmappe/fil.jpg" ?

Jeg roder ikke med egen PHP-server.

Jeg kan ikke se at man har brug for at lægge noget uden for
web-afdelingen.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen <nospamius@lundhansen.dk> wrote:

> Jeg kan ikke se at man har brug for at lægge noget uden for
> web-afdelingen.

Jeg benytter det, når der er tale om billeduploads eller
serverside-generering af billeder - i de tilfælde skal der være
skriverettigheder til mappen med billederne.

Tilsvarende har jeg alle mine .inc-filer - samt .php-filer
indeholdende diverse funktioner - placeret i en mappe udenfor
public_html.

Begge ovennævnte tilfælde har sine mere eller mindre paranoider
årsager: det holder indholdet isoleret fra pilfingre (skønt
sandsynligheden for at een eller anden skulle gætte, at der
eksisterer fil foo.inc et givent sted nok er minimal), plus det gør
det mere overskueligt mht. vedligeholdelse.

--
Anders Thorsen Holm, BSc i datalogi-multimedier.

Jeg søger fuldtidsjob i Århus - gerne studierelevant, men ingen
betingelse. Læs mit CV: http://www.thorsenholm.dk/cv/

---

Bertel Lund Hansen skrev:

> Anders Lund skrev:
>>Ah, ja. Det er fordi jeg har brugt det til at komme "uden for" web-root,
>>for at få fat i nogle filer, som brugeren ikke måtte kunne få fat i. :)
>
> Det kan man vist ikke på et normalt webhotel eller en almindelig
> hjemmeside hos en udbyder.

det kommer da an på hvad et normalt webhotel er, jeg har det som
mulighed på flere af mine projekter hos normale udbydere til nogle
hundrede kroner om året, så jeg synes egentlig ikke det er en vild feature.

>>Kan det gøres på anden måde? "/../hemligmappe/fil.jpg" ?

Aner det ikke, jeg plejer at putte antallet af '../' i en variabel som
jeg sætter foran alle includes, så virker de altid :)

> Jeg kan ikke se at man har brug for at lægge noget uden for
> web-afdelingen.

Jeg plejer at lægge mysql-adgangsoplysninger uden for webroden, bare som
ekstra sikkerhed :)

mvh

Jesper Brunholm

---

"Søren Blom" <soren@blom.dk> wrote in message
news:41260813$0$159$edfadb0f@dtext02.news.tele.dk...
> Er lidt på herrerens mark, så jeg håber at I kan hjælpe med måske nogen
> indlysende svar, som jeg dog ikke lige kan regne ud.
>
> I min iver for at optimere mit web-site, så er jeg gået igang med at lave
en
> ny fil struktur på det dog driller det lidt. Bruger en menubar som bliver
> kaldt ved hjælp af
>
> <?
> require("menubar.inc");
> ?>
>
> Hidtil har menubar lagt i roden og i et par enkel biblioteker på sitet,
men
> jeg tænkte på om jeg kan lave noget, så menubaren kan nøjes med at lægge
eet
> central sted som alle under sider kan trække på, også selv om den lægge i
> andre biblioteker end menubar.inc filen lægger,

Jeg er ikke sikker på jeg har forstået dig 100%, men hvis du anvender / er
du uafhængig af hvorfra du kalder filen:

require ("/mappe/menubar.inc");

Afhængig af konfigurationen af den server du ligger på kan / pege helt
tilbage til filsystemets rod, eller f.eks. til roden af dit website mm, så
der må du lige prøve dig frem.

Mvh
Jimmy

---

"Jimmy" <nyhedsgruppe2001@SPAM.yahoo.co.uk> wrote in message
news:41260c3a$0$207$14726298@news.sunsite.dk...
>
> "Søren Blom" <soren@blom.dk> wrote in message
> news:41260813$0$159$edfadb0f@dtext02.news.tele.dk...
> > Er lidt på herrerens mark, så jeg håber at I kan hjælpe med måske nogen
> > indlysende svar, som jeg dog ikke lige kan regne ud.
> >
> > I min iver for at optimere mit web-site, så er jeg gået igang med at
lave
> en
> > ny fil struktur på det dog driller det lidt. Bruger en menubar som
bliver
> > kaldt ved hjælp af
> >
> > <?
> > require("menubar.inc");
> > ?>
> >
> > Hidtil har menubar lagt i roden og i et par enkel biblioteker på sitet,
> men
> > jeg tænkte på om jeg kan lave noget, så menubaren kan nøjes med at lægge
> eet
> > central sted som alle under sider kan trække på, også selv om den lægge
i
> > andre biblioteker end menubar.inc filen lægger,
>
> Jeg er ikke sikker på jeg har forstået dig 100%, men hvis du anvender / er
> du uafhængig af hvorfra du kalder filen:
>
> require ("/mappe/menubar.inc");
>
Du kan jo bruge require($_SERVER["DOCUMENT_ROOT"]."/include/menubar.php");
På den måde er du sikker på altid at få den peget det rigtige sted hen.!

Så vidt jeg husker altså..

/iM

---

Søren Blom wrote:

> <?
> require("menubar.inc");
> ?>

Du kan sætte et base-dir med eg. htaccess (hvis du bruger Apache og har
lov til .htaccess).

---- .htaccess ----
php_value include_path /home/www/example
----------------------

Du kan også bruge set_include_path()

Læg de filer, der skal bruger i en mappe, som du har angivet i din
..htaccess eller med set_include_path(), så kan du fyre require() eller
include() af, hvor det passer dig.

Lidt læsning:

http://dk.php.net/manual/en/ini.sect.path-directory.php#ini.include-path
http://dk.php.net/manual/en/function.set-include-path.php


--
Mvh
Tonni Aagesen
www.cazoo.dk

---

"Tonni Aagesen" <goto@dev.null> skrev
>
> ---- .htaccess ----
> php_value include_path /home/www/example
> ----------------------
>
> Du kan også bruge set_include_path()
>
> Læg de filer, der skal bruger i en mappe, som du har angivet i din
> .htaccess eller med set_include_path(), så kan du fyre require() eller
> include() af, hvor det passer dig.
>
> Lidt læsning:
>
> http://dk.php.net/manual/en/ini.sect.path-directory.php#ini.include-path
> http://dk.php.net/manual/en/function.set-include-path.php
>

Jeg siger tak for al hjælpen, håber at få kikkede lidt mere grundigt på det
her i weekenden, men jer der har besvaret, er helt sikker skyld i at jeg
vender tilbage til gruppen, enten fordi jeg bare intet kan få til at virke
eller fordi nye ideer opstår som jeg skal have hjælp til.
Det er ikke sådan når man ikke er den skarpeste kniv i skuffen.

--
VH

Søren Blom
soren@blom.dk
Mail med spam filter besvares ikke.

---

I news:4126792a$0$164$edfadb0f@dtext02.news.tele.dk skrev
Søren Blom følgende:

> Det er ikke sådan når man ikke er den skarpeste kniv i skuffen.

Velkommen i klubben

Jeg har fået megen og god hjælp her i gruppen.

--
Med venlig hilsen Andreas Falck - ICQ 108 480 093
http://maranatha.dk/ + http://skabelsen.info/
http://ravsted.dk/ - *Byen hvor der virkelig sker noget*
http://ravsted.net/ - *Lokalhistoriske sider*

---

Tonni Aagesen wrote:

> Læg de filer, der skal bruger i en mappe, som du har angivet i din
> ..htaccess eller med set_include_path(), så kan du fyre require() eller
> include() af, hvor det passer dig.

Jeg formår virkelig at konstruere nogle spøjse sætninger, når jeg har
travlt :)


--
Mvh
Tonni Aagesen
www.cazoo.dk

---

Hej NG

To tillægsspørgsmål:

Hvad er forskellen på <? require("menu.inc"); ?> og <? include("menu.inc");
?>

Kan man i flæng bruge relativ eller absolut sti, når man i php vil inkludere
noget? Jeg mener, i ssi skal der bruges <!--#include file="menu.inc"--> ,
hvis man vil bruge relativ sti og <!--#include virtual="menu.inc"--> , hvis
man vil bruge absolut sti.

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

---

On Sun, 22 Aug 2004 00:33:11 +0200, Erik Ginnerskov wrote:

>
> Hvad er forskellen på <? require("menu.inc"); ?> og <?
> include("menu.inc"); ?>
>
require er unconditional og giver fejl ved manglende fil - eksekvering af
script stopper.
include er conditional og giver warning ved manglende fil - eksekvering af
script stopper ikke.
include kan bruges i en if-konstruktion, det kan require ikke.

> Kan man i flæng bruge relativ eller absolut sti
Ja.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Q:   How was Thomas J. Watson buried?
A:   9 edge down.

---

Michael Rasmussen wrote:

> require er unconditional og giver fejl ved manglende fil -
> eksekvering af script stopper.

På samme måde, som hvis en inkluderet fil i en asp-side gør, at siden slet
ikke kan vises? - om det så bare er en lille dum pil, der linkertil sidens
top.

> include er conditional og giver warning ved manglende fil -
> eksekvering af script stopper ikke.

Jeg har bemærket, at en side vises i den udstrækning komponenterne kan
lokaliseres og at der kommer en warning for det manglende.

> include kan bruges i en if-konstruktion, det kan require ikke.

Så langt er jeg slet ikke kommet mht. at lære php. 8)

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

---

On Sun, 22 Aug 2004 01:05:01 +0200, Erik Ginnerskov wrote:

>
> På samme måde, som hvis en inkluderet fil i en asp-side gør, at siden
> slet ikke kan vises? - om det så bare er en lille dum pil, der linkertil
> sidens top.
>
Det skal jeg ikke kunne svare på; jeg har aldrig lavet noget i asp
>
> Så langt er jeg slet ikke kommet mht. at lære php. 8)
Det er helt ok Det er i øvrigt en ret smart ting. Forestil dig at du
har en menu, hvor forskellige personer har forskellige muligheder; du vil
da kunne inkluderer et script med netop de muligheder, der skal være
tilgængelig for den aktuelle person.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Debian Hint #18: You can see all of the current bugs for a given package by
going to http://bugs.debian.org/

---

Erik Ginnerskov wrote:
> Hej NG
>
> To tillægsspørgsmål:
>
> Hvad er forskellen på <? require("menu.inc"); ?> og <? include("menu.inc");
> ?>

"require() and include() are identical in every way except how they
handle failure. include() produces a Warning while require() results in
a Fatal Error. In other words, don't hesitate to use require() if you
want a missing file to halt processing of the page. include() does not
behave this way, the script will continue regardless."

   Fra http://dk.php.net/require

Men når det så er sagt, skal der også indskydes en kommentar :)

Jeg mener helt bestemt at der i "gamle dage" (PHP3), var yderligere en
forskel. Nemlig at "include" filer kun blev includet, hvis den linje
hvor include'n, stod på blev afviklet, mens "require" filer, altid blev
inkluderet (uagtet om linjen hvor require'n stod på blev afviklet eller ej).

Det betød at hvis man f.eks. havde en konstruktion ala denne:
   
   if( $someVar=="someValue" ) {
      include('fil.php');
   }

Så ville filen 'fil.php' altså kun blive inkluderet, hvis
$somerVar=="someValue" var sandt.

Men hvis der stod:
   if( $someVar=="someValue" ) {
      require('fil.php');
   }
Så ville filen 'fil.php' blive inkluderet, uanset om
$someVar=="someValue" var sandt eller falsk.

Men sådan er det ikke længere, så hvis det forvirrer mere end det gavner
(og du ikke skal rette i "gamle" scripts), så bare glem det ;)


>
> Kan man i flæng bruge relativ eller absolut sti, når man i php vil inkludere
> noget? Jeg mener, i ssi skal der bruges <!--#include file="menu.inc"--> ,
> hvis man vil bruge relativ sti og <!--#include virtual="menu.inc"--> , hvis
> man vil bruge absolut sti.
>

Jeg er ikke benhård i SSI, men jeg mener nu ikke at det er forskellen.
Forskellen på file og virtual er at file er ift filsystemet på din
server, mens virtual er i forhold til dit webhomes rodmappe.

Dvs. hvis f.eks. dit webhome ligger i mappen /var/www/domaenedk
så vil <!--#include file="/menu.inc"--> inkludere den fil, der hedder
"menu.inc", som ligger i roden af dit filsystem (altså ikke i
/var/www/domaenedk/menu.inc" men bare "/menu.inc".

<!--#include virtual="/menu.inc"--> vll inkludere den fil, der ligger i
dit webhomes rodmappe. Altså filen "/var/www/domaenedk/menu.inc".

Hvis du har 2 sider, der ligger i dit webhomes rodmappe, og den ene fil,
bruger <!--#include virtual="menu.inc"--> og den anden bruger
<!--#include file="menu.inc"-->, så vil de inkludere den samme fil.

Men hvis du nu forestiller dig at du flytter de to filer ind i en mappe
under dit webhomes rodmappe (f.eks. /var/www/domaenedk/enmappe),
så vil den fil der bruger <!--#include virtual="menu.inc"--> inkludere
den samme fil som før (nemlig /var/www/domaenedk/menu.inc), da virtual
er relativ i forhold til dit webhomes rodmappe.

Men den fil der bruger <!--#include file="menu.inc"-->, vil nu inkludere
en anden fil (nemlig /var/www/domaenedk/enmappe/menu.inc), da file altid
er relativ ift. filsystemet.


Og for så at svare på dit spørgsmål :)

Ja, man kan i flæng bruge relative og absolutte stier i require,
require_once, include og include_once.
Stierne er altid i forhold til filsystemet på din server (altså ligesom
<!--#include file="menu.inc"-->)

Der er altså ingen "virtual", man kan dog (i de fleste tilfælde[1]) opnå
samme effekt, ved at bruge f.eks.
   require( $_SERVER['DOCUMENT_ROOT'].'/menu.inc' );

I sin php.ini fil, kan man også sætte en "include_path", man behøver
ikke angive stien til filer, der ligger i ens include_path.

Dvs. hvis f.eks. include_path='/var/php/includes' og du i
/var/php/includes har filen menu.inc, så behøver du bare at skrive
   require('menu.inc');

Du kan læse mere om include_path på:
http://dk.php.net/manual/da/ini.sect.path-directory.php#ini.include-path

MVH Per Thomsen,
http://www.pert.dk/

[1] DOCUMENT_ROOT er en miljøvariabel, som serveren _kan_ sætte, jeg er
endnu ikke stødt på en server, hvor den ikke er sat, men det kan dog
forekomme.

---

Per Thomsen wrote:
[klip]
>
> Jeg mener helt bestemt at der i "gamle dage" (PHP3), var yderligere en
> forskel. Nemlig at "include" filer kun blev includet, hvis den linje
> hvor include'n, stod på blev afviklet, mens "require" filer, altid blev
> inkluderet (uagtet om linjen hvor require'n stod på blev afviklet eller
> ej).
[klip]

Jeg retter lige mig selv :)

Hvis jeg nu havde læst en lille smule længere på den side i manualen,
jeg selv referede til, ville jeg have set at "gamle dage" var PHP ældre
end 4.0.2

"Prior to PHP 4.0.2, the following applies: require() will always
attempt to read the target file, even if the line it's on never
executes. The conditional statement won't affect require(). However, if
the line on which the require() occurs is not executed, neither will any
of the code in the target file be executed. Similarly, looping
structures do not affect the behaviour of require(). Although the code
contained in the target file is still subject to the loop, the require()
itself happens only once."

   fra http://dk.php.net/require

MVH Per Thomsen,
http://www.pert.dk/

---

Per Thomsen wrote:

> Hvis jeg nu havde læst en lille smule længere på den side i manualen,
> jeg selv referede til, ville jeg have set at "gamle dage" var PHP
> ældre end 4.0.2

Never mind about that. Jeg starter med php der, hvor php er kommet til nu og
skal ikke rode med at rette i gamle scripter.

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

---

Per Thomsen wrote:

> Det betød at hvis man f.eks. havde en konstruktion ala denne:
>
> if( $someVar=="someValue" ) {
> include('fil.php');
> }
>
> Så ville filen 'fil.php' altså kun blive inkluderet, hvis
> $somerVar=="someValue" var sandt.
>
> Men hvis der stod:
> if( $someVar=="someValue" ) {
> require('fil.php');
> }
> Så ville filen 'fil.php' blive inkluderet, uanset om
> $someVar=="someValue" var sandt eller falsk.

Sidstnævnte opfatter jeg som en ulogisk konstruktion - en
programmeringsfejl, der modsiger if-sætningen.

>> Kan man i flæng bruge relativ eller absolut sti, når man i php vil
>> inkludere noget? Jeg mener, i ssi skal der bruges <!--#include
>> file="menu.inc"--> , hvis man vil bruge relativ sti og <!--#include
>> virtual="menu.inc"--> , hvis man vil bruge absolut sti.

> Hvis du har 2 sider, der ligger i dit webhomes rodmappe, og den ene
> fil, bruger <!--#include virtual="menu.inc"--> og den anden bruger
> <!--#include file="menu.inc"-->, så vil de inkludere den samme fil.
>
> Men hvis du nu forestiller dig at du flytter de to filer ind i en
> mappe under dit webhomes rodmappe (f.eks. /var/www/domaenedk/enmappe),
> så vil den fil der bruger <!--#include virtual="menu.inc"--> inkludere
> den samme fil som før (nemlig /var/www/domaenedk/menu.inc), da virtual
> er relativ i forhold til dit webhomes rodmappe.

Jeg har brugt 'include file' i et par år, så det har jeg helt fat i. Nu skal
jeg så bare gennemskue hele systemet med 'include virtual'

> Og for så at svare på dit spørgsmål :)
> Ja, man kan i flæng bruge relative og absolutte stier i require,
> require_once, include og include_once.
> Stierne er altid i forhold til filsystemet på din server (altså
> ligesom <!--#include file="menu.inc"-->)
>
> Der er altså ingen "virtual", man kan dog (i de fleste tilfælde[1])
> opnå samme effekt, ved at bruge f.eks.
> require( $_SERVER['DOCUMENT_ROOT'].'/menu.inc' );

Jeg har allerede 'snakket med' $_SERVER["DOCUMENT_ROOT"] i forbindelse med
noget .htacces-opsætning.

> I sin php.ini fil, kan man også sætte en "include_path", man behøver
> ikke angive stien til filer, der ligger i ens include_path.

> Du kan læse mere om include_path på:
> http://dk.php.net/manual/da/ini.sect.path-directory.php#ini.include-path

I'll do that.

Tak for omfattende info.

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