---

Hej (:

Hvilket fil-format skal jeg gemme i, hvis jeg vil have, det jeg
har lavet på alle mine sider? f.eks. en menu, bokse og
logo/billede, der skal være på alle sider. Og hvilken kode skal
jeg skrive på alle mine sider?
håber I kan hjælpe mig.(:

mvh. Camilla.

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

---

Den Wed, 18 Feb 2009 13:54:20 +0000 skrev Camilla:

> Hej (:
>
> Hvilket fil-format skal jeg gemme i, hvis jeg vil have, det jeg har
> lavet på alle mine sider? f.eks. en menu, bokse og logo/billede, der
> skal være på alle sider. Og hvilken kode skal jeg skrive på alle mine
> sider?
> håber I kan hjælpe mig.(:
>
> mvh. Camilla.

..css

Du skal vist i gang med at studere CSS.
http://www.html.dk/tutorials/css/

---
Karl Erik.

---

Karl Erik Christensen wrote:

> Du skal vist i gang med at studere CSS.
> http://www.html.dk/tutorials/css/

Det er kun få dage siden, du hakkede på andre for ikke at svare præcis på
det, der blev spurgt om. Nu kommer du selv med et svar, der er 'goddag mand,
økseskaft'.

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

---

Camilla skrev:

> Hvilket fil-format skal jeg gemme i, hvis jeg vil have, det jeg
> har lavet på alle mine sider? f.eks. en menu, bokse og
> logo/billede, der skal være på alle sider.

Du vil gerne lave én menu, men sørge for at den ses på alle
sider.

Der er to metoder:
Den ene hedder Server Side Include, SSI, og den anden består i at
man benytter et serverside-scriptsprog. Jeg bruger selv det
sidste.

Der findes flere forskellige serverside-scriptsprog, men jeg
bruger PHP. Du behøver ikke lære PHP for at løse dit problem. Det
kan klares meget enkelt. Der er blot et par regler du skal følge.

Din hovedfil laver du som normalt, men den skal have filendelsen
..php.

Du laver en menu i en selvstændig fil. Det må *ikke* være en
komplet HTML-fil. Den må kun lige indeholde det som du normalt
ville skrive på menuens plads i hovedfilen. Filen skal gemmes med
den 'dobbelte' filendelse .inc.php. Lad os kalden den "menu" -
altså "menu.inc.php":

I hovedfilen fjerner du så menuen, og i stedet skriver du denne
linje:

   <?php include "menu.inc.php" ?>

Det forudsætter at hovedfilen og menufilen ligger i samme mappe
på serveren.

Andet skal der ikke til. Hvis din indgangsfil nu hedder
index.htm(l), skal den nu hedde index.php. Den bliver åbnet
automatisk når man blot skriver adressen på hjemmesiden, hvis du
husker at fjerne den gamle HTML-fil..

> Og hvilken kode skal jeg skrive på alle mine sider?

1. Omdøb filerne til at hedde .php som filtype.
2. Fjern den gamle menu (hvis der er en) og indsæt include-linjen
i stedet.

Logoet kan indsættes på lignende måde.

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

---

Bertel Lund Hansen wrote:

> Filen skal gemmes med
> den 'dobbelte' filendelse .inc.php. Lad os kalden den "menu" -
> altså "menu.inc.php":

Hvorfor dog det? Filen skal da ikke nødvendigvis have den endelse, og slet
ikke en "dobbelt". Faktisk er det lidt meningsløst at give den endelsen
..php - der er jo ikke noget der skal fortolkes før den /er/ inkluderet.
Filnavnet "menu.txt" vil være helt i orden.

--
Kurt Lund

---

Kurt Lund skrev:
> Hvorfor dog det? Filen skal da ikke nødvendigvis have den endelse, og slet
> ikke en "dobbelt". Faktisk er det lidt meningsløst at give den endelsen
> .php - der er jo ikke noget der skal fortolkes før den /er/ inkluderet.
> Filnavnet "menu.txt" vil være helt i orden.

Jeg vil delvist give dig ret.

Det er meningløst at lade folk tro det har en betydning om filendelsen
er .inc.php eller .php

Men jeg finder det ikke meningsløst at filendelsen er .php selvom det er
en fil PHP skal inkludere.

For det første giver det god mening at navngive PHP filer med
filendelsen .php - der er trods alt PHP i.

Den anden grund er at PHP parses og dermed vises kildekoden ikke hvis
PHP filen kaldes direkte. Det er ikke alle udbydere der tillader filer
uden for webscope.

Den tredie grund er at nybegyndere muligvis ikke er for god til at
strukturere og passe på sin kode, så der er ingen grund til at vise
kildekoden som rent tekstindhold. Lad PHP parse filen så kildekoden kan
være skjult.


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

Tro ikke brugerne vil gøre noget for at undgå dit killfilter
- Så vigtig er du heller ikke!

---

Dan Storm skrev:
> Kurt Lund skrev:
>> Hvorfor dog det? Filen skal da ikke nødvendigvis have den endelse, og
>> slet ikke en "dobbelt". Faktisk er det lidt meningsløst at give den
>> endelsen .php - der er jo ikke noget der skal fortolkes før den /er/
>> inkluderet. Filnavnet "menu.txt" vil være helt i orden.
>
> Jeg vil delvist give dig ret.
>
> Det er meningløst at lade folk tro det har en betydning om filendelsen
> er .inc.php eller .php
>

Hvis en parser støder på en fil, der er beregnet
til inkludering gælder det vel om at have en extension
som parseren ikke kender. Ellers parses jo netop som en
stand-alone fil på webstedet. i værste fald et link på
Google der fører til ens sidefod? Eller hvad?

Sådan lød argumentet i hvert fald første gang jeg hørte det,
og brugte derfor endelsen inc.


--

Med venlig hilsen
Jørgen Farum Jensen
Håndbog i webdesign: http://webdesign101.dk/wwwbog/udgave2/
Webdesign med stylesheets: http://webdesign101.dk/cssbog/
..

---

Jørgen Farum Jensen skrev:
> Hvis en parser støder på en fil, der er beregnet
> til inkludering gælder det vel om at have en extension
> som parseren ikke kender. Ellers parses jo netop som en
> stand-alone fil på webstedet. i værste fald et link på
> Google der fører til ens sidefod? Eller hvad?

Forestil dig en mappe og filstruktur (kun et eksempel, ikke et oplæg til
debat om hvordan det kan gøres smartere ;) ):

+ docs/
|--+ includes/
| |- sqlFunctions.php
| |- htmlHeader.php
| |- htmlFooter.php
|
|--+ img/
|--+ objects/
|
|- index.php
|- contact.php
|- about.php


I index.php kunne der så stå følgende:
<?php
   // Hent header HTML
   include("includes/htmlHeader.php");

?>
Blah blah blah mit indhold, eventuelt inkludere sqlFunctions.php og
smide noget indhold fra databasen ud - måske nogle nyheder.
<?php
   // Hent footer HTML
   include("includes/htmlFooter.php");

?>


I det her tilfælde 'linker' du jo ikke til dine includefiler og google
bør ikke opfange dine includefiler og derefter linke til dem.

i sqlFunctions.php kunne du så have noget ala:
<?php

   mysql_connect("localhost", "mit_brugernavn", "mit_kodeord");
   mysql_select_db("min_database");

   /* Funktioner herunder som letter dit arbejde med MySQL. */

?>

Hvis jeg henter den via browseren
(http://example.org/includes/sqlFunctions.php) præsenteres jeg for
ingenting.
En tom side uden nogen form for indhold som du kan bruge til noget som
helst.

Hvis vi nu omdøbte den til .inc og hentede den via browseren
(http://example.org/includes/sqlFunctions.inc) vil du få et resultat
frem som viser den skrevne kode. Dit brugernavn og kodeord er så
komprimitteret - og man kan somregel regne med at FTP brugernavn og
kodeord er det samme.

Ovenstående eksempel er ikke så ualmindeligt, særligt for knap så øvede
PHP scriptere.

> Sådan lød argumentet i hvert fald første gang jeg hørte det,
> og brugte derfor endelsen inc.

Argumentet er er lidt usammenhængende (i mine ører, anyway) idet at det
lyder som om at PHP parseren er delvist ansvarlig for visning af de
filer der er tilgængelige på websitet.

Men altså, der er ingen grund til at ikke angive filendelsen ud fra det
indhold der er i filen. .php til PHP, .gif til GIF billeder, .txt til
tekstfiler og så videre.


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Kurt Lund skrev:

> > Filen skal gemmes med den 'dobbelte' filendelse .inc.php.

> Hvorfor dog det?

Jeg overvejede at skrive en forklaring for nørder, men besluttede
at det var mere overskueligt for en begynder at jeg blot skrev
"skal" uden forklaring.

1. inc fordi det er en include-fil. Det er godt at kunne se på
filnavnet hvad dens funktion er.
2. php fordi det betyder at hvis filen bestilles ved et uheld, så
kan brugeren kun se det som det var meningen. Hvis den f.eks. kun
indeholder funktioner, får man bare en tom side.

> Filen skal da ikke nødvendigvis have den endelse, og slet
> ikke en "dobbelt".

Rent teknisk er det korrekt.

> Faktisk er det lidt meningsløst at give den endelsen .php -

Tværtimod. Forestil dig en includefil med et kodeord i (ikke det
smarteste setup, men så forstår du princippet). Hvis den hedder
dat til efternavn, kan enhver læse hele indholdet ved at
adressere filen direkte. Hvis den hedder php til efternavn, kan
man ikke.

> Filnavnet "menu.txt" vil være helt i orden.

Det er en god idë fra starten at grundlægge en vane som sparer en
for bekymringer i fremtiden og som ikke giver
uhensigtsmæssigheder. Derfor anbefaler jeg .inc.php til *alle*
includefiler.

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

---

Bertel Lund Hansen skrev:

> Det er en god idë fra starten at grundlægge en
> vane som sparer en for bekymringer i fremtiden
> og som ikke giver uhensigtsmæssigheder.

Grundlæggende er jeg helt enig.

> Derfor anbefaler jeg .inc.php til *alle* includefiler.

Selv bruger jeg ofte txt-filer til lange lister, fordi det
er nemt at rette i - og skulle nogen ved en tilfældighed
få adgang til den, er der ikke noget hemmelig kode i
den.

I andre tilfælde bruger jeg csv-filer, der kan redigeres
direkte i Excel.

Se også http://html-faq.dk/2027.asp

--
Allan Vebel
http://html-faq.dk
http://vebel.dk

---

Bertel Lund Hansen wrote:

> Derfor anbefaler jeg .inc.php til *alle* includefiler.

Det er kun nødvendigt med dobbelt endelse, hvis serveren tillader at hente
filer med endelsen .inc - lav en hurtig test og får man intet retur, kan man
fint nøjes med 'menu.inc'.

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

---

Erik Ginnerskov skrev:

> Det er kun nødvendigt med dobbelt endelse, hvis serveren tillader at
> hente filer med endelsen .inc - lav en hurtig test og får man intet
> retur, kan man fint nøjes med 'menu.inc'.

Det er vel ikke kun et spørgsmål, om serveren tillader .inc. Det er vel
også et spørgsmål om, om den kan afvikle php-kode fra en .inc-fil.
På mit eget localhost er det ikke noget problem, men jeg har oplevet
webhoteller, hvor den ikke gik. Hele php-koden var synlig.

Jeg gider ikke at skulle teste det for hvert webhotel, så jeg laver bare
dobbelte endelser. Så er jeg sikker på at det virker, også hvis jeg en
dag skulle skifte udbyder.


--
Philip - http://chartbase.dk

---

Philip Nunnegaard wrote:

> Det er vel ikke kun et spørgsmål, om serveren tillader .inc. Det er
> vel også et spørgsmål om, om den kan afvikle php-kode fra en .inc-fil.
> På mit eget localhost er det ikke noget problem, men jeg har oplevet
> webhoteller, hvor den ikke gik. Hele php-koden var synlig.

En klar fejlfunktion på serveren. Normalen er, at includes køres først,
hvorefter serverside scripting sendes gennem parseren.

Det skulle betyde, at selv om der er php-kode i en inkludered fil, bliver
det behandlet som php og ikke sendt som klar tekst.

Det er også derfor, man ikke uden videre kan lave et include, der er
afhængig af udfaldet af et serverside scripts kørsel.

På de webhoteller, jeg har plads hos, fungerer det helt gnidningsløst sådan.

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

---

Erik Ginnerskov skrev:
> Philip Nunnegaard wrote:
>
>> Det er vel ikke kun et spørgsmål, om serveren tillader .inc. Det er
>> vel også et spørgsmål om, om den kan afvikle php-kode fra en .inc-fil.
>> På mit eget localhost er det ikke noget problem, men jeg har oplevet
>> webhoteller, hvor den ikke gik. Hele php-koden var synlig.
>
> En klar fejlfunktion på serveren. Normalen er, at includes køres først,
> hvorefter serverside scripting sendes gennem parseren.

For mig lader det til at Philip har kørt inc filen direkte i browseren
og ikke kaldt den gennem en include().

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Dan Storm skrev:

> For mig lader det til at Philip har kørt inc filen direkte i browseren
> og ikke kaldt den gennem en include().

Jeg har selvfølgelig kaldt den via include fra en .php-fil, men som
nævnt andetsteds muligvis på en windowsserver.


--
Philip - http://chartbase.dk

---

Philip Nunnegaard wrote:

> Jeg har selvfølgelig kaldt den via include fra en .php-fil, men som
> nævnt andetsteds muligvis på en windowsserver.

Både hjemmesideskolen.dk html-faq.dk ligger på en Windows-server med
php-plugin. Der er ingen slinger i valsen der. Filer med endelsen .inc kan
ikke hentes direkte. Alle includes køres problemfrit, uanset om det er asp
eller php. Al php- eller asp-kode i inkluderede filer parses altid.

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

---

Dan Storm wrote:

> For mig lader det til at Philip har kørt inc filen direkte i browseren
> og ikke kaldt den gennem en include().

Og det skal man selvfølgelig være sikker på, at serveren ikke tillader.

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

---

Philip Nunnegaard skrev:

> Jeg gider ikke at skulle teste det for hvert webhotel, så jeg laver bare
> dobbelte endelser. Så er jeg sikker på at det virker, også hvis jeg en
> dag skulle skifte udbyder.

Nemlig.


MVH
Rune Jensen

---

Erik Ginnerskov skrev:

> Det er kun nødvendigt med dobbelt endelse, hvis serveren tillader at hente
> filer med endelsen .inc - lav en hurtig test og får man intet retur, kan man
> fint nøjes med 'menu.inc'.

Du overser min vigtigste pointe:

Med mit system skal man *aldrig* huske at få gjort et eller andet
ekstra.

Der er 117 måder at sikre includefiler på, men alle de andre
kræver at man laver om på en indstilling, og det skal man så
huske at gøre igen hvis man flytter tingene.

Brug kun websikre tegn er et andet råd jeg giver. Bevares, en
hurtig test kan sikkert vise at man kan bruge et mylder af andre
tegn - på den specifikke server med den specifikke opsætning den
lige har i dag.

Men hvorfor lægge grunden til bøvl der opstår den dag tingene
ændrer sig når man med en simpel vedtægt kan sikre sig imod
problemer én gang for alle?

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

---

Bertel Lund Hansen <unospamo@lundhansen.dk> writes:

>> > Filen skal gemmes med den 'dobbelte' filendelse .inc.php.
....
> Forestil dig en includefil med et kodeord i (ikke det
> smarteste setup, men så forstår du princippet). Hvis den hedder
> dat til efternavn, kan enhver læse hele indholdet ved at
> adressere filen direkte. Hvis den hedder php til efternavn, kan
> man ikke.

Det er lidt en "fattigmandsløsning" på problemet. En pænere løsning
ville være at lægge include-filer i et directory der ikke udstilles
af web-serveren eller at konfigurere web-serveren til ikke at sende
inc-filer.

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen skrev:
> Det er lidt en "fattigmandsløsning" på problemet. En pænere løsning
> ville være at lægge include-filer i et directory der ikke udstilles
> af web-serveren eller at konfigurere web-serveren til ikke at sende
> inc-filer.

Det er ikke alle udbydere der tillader at lægge filer uden for webscope.
Typisk billigere hosts for dem som ikke har det vilde behov eller den
nødvendige erfaring/kompetence.

Ligeledes med serveropsættet - det er ikke alle brugere der har styr på
..htaccess og kan lave den løsning.

Men udover det, så kan jeg ikke se problemet i at navngive filer efter
indholdet. .php til PHP filer. Så slipper du for bøvlet med
seropsætningen og for at sikre dig at alle dine include filer ligger
uden webscope.

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Dan Storm wrote:
>> Det er lidt en "fattigmandsløsning" på problemet. En pænere løsning
>> ville være at lægge include-filer i et directory der ikke udstilles
>> af web-serveren eller at konfigurere web-serveren til ikke at sende
>> inc-filer.
>
> Det er ikke alle udbydere der tillader at lægge filer uden for
> webscope. Typisk billigere hosts for dem som ikke har det vilde behov
> eller den nødvendige erfaring/kompetence.

Det var heller ikke det, Lasse foreslog. .inc-filer kan indenfor webscope
lægges i en mappe, der ikke indeholder andet end netop .inc-filer og som der
ikke linkes til på anden måde. Så vil google ikke finde filerne og dermed
heller ikke indeksere dem.

Men det, der er nemmest at administrere, er, at serveren simpelthen ikke
sender filer med endelsen .inc - så kan man have sine includes liggende,
hvor de skal bruges.

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

---

Erik Ginnerskov skrev:
> Det var heller ikke det, Lasse foreslog. .inc-filer kan indenfor
> webscope lægges i en mappe, der ikke indeholder andet end netop
> .inc-filer og som der ikke linkes til på anden måde. Så vil google ikke
> finde filerne og dermed heller ikke indeksere dem.

Ja, okay, så misforstod jeg indlægget.

> Men det, der er nemmest at administrere, er, at serveren simpelthen ikke
> sender filer med endelsen .inc - så kan man have sine includes liggende,
> hvor de skal bruges.

Jeg mener nu stadig at PHP hører til i .php filer.
Jeg gør selv som Bertel foreslog.
iCore.inc.php

Om man så vil sætte serveren op til ikke at sende .inc.php filer er jo
så op til en selv (mulighed og kompetence).

--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Dan Storm wrote:

> Om man så vil sætte serveren op til ikke at sende .inc.php filer er jo
> så op til en selv (mulighed og kompetence).

Er der tale om en Apache-server, kan det hurtigt indsættes i .htaccess :

<Files *.inc>
order allow,deny
deny from all
</Files>

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

---

Erik Ginnerskov skrev:
> Er der tale om en Apache-server, kan det hurtigt indsættes i .htaccess :

Jeg ved godt hvordan man gør.
Men det er der andre der ikke gør.

Men ser du nogen fordel i at bruge .inc?


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Dan Storm skrev:

> Men ser du nogen fordel i at bruge .inc?

Jeg kan se en fordel: I mit TotalCommander har jeg filerne sorteret
efter filtype, så her ville .inc stå for sig selv, mens .inc.php er
blandet sammen med .php.

Men bortset fra det, så hører jeg selv til dem der ikke tør røre ved
..htaccess (og mit behov for at lære det har endnu ikke overgået
manglerne i min evne til at forstå engelsk), så jeg lever med .inc.php.


--
Philip - http://chartbase.dk

---

Philip Nunnegaard skrev:

> Men bortset fra det, så hører jeg selv til dem der ikke tør røre ved
> .htaccess

Jeg tør godt - men jeg tør sgu ikke garantere at jeg husker at få
det gjort hvis jeg skifter webhoteludbyder.

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

---

Bertel Lund Hansen wrote:

> Jeg tør godt - men jeg tør sgu ikke garantere at jeg husker at få
> det gjort hvis jeg skifter webhoteludbyder.

Du er da ellers langtfra ukendt med at dokumentere dit arbejde?

--
Kurt Lund

---

Philip Nunnegaard wrote:

> Men bortset fra det, så hører jeg selv til dem der ikke tør røre ved
> .htaccess

Du skal bare betragte det som 'yet another .ini file'.
Med andre ord, det er bare en konfigurationsfil med noget xml-alike syntaks.

--
Med venlig hilsen
Stig Johansen

---

Dan Storm wrote:

> Men ser du nogen fordel i at bruge .inc?

Ren og skær dovenskab. Jeg sparer 4 karakterer i hvert filnavn.

Synes dog også, det giver bedre overblik både i min editor og i min ftp, når
includes ender på .inc. Med dobbelt endelse bliver .inc vist som en del af
filnavnet og ikke som en del af endelsen.

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

---

Erik Ginnerskov skrev:
> Ren og skær dovenskab. Jeg sparer 4 karakterer i hvert filnavn.

hehe :p

> Synes dog også, det giver bedre overblik både i min editor og i min ftp,
> når includes ender på .inc. Med dobbelt endelse bliver .inc vist som en
> del af filnavnet og ikke som en del af endelsen.

Tja, det er selvfølgelig et spørgsmål om vane.

For mig skaber det overblik at .inc er en del af filnavnet.
Ligesom alle mine objekt-filer hedder noget i stil med
cMysql.obj.php

Men det er jo bare den stil jeg har :)


--
Dan Storm - storm at err0r dot dk / http://err0r.dk

People who claim they don't let little things bother
them have never slept in a room with a single mosquito.

---

Erik Ginnerskov skrev:

> Er der tale om en Apache-server, kan det hurtigt indsættes i .htaccess :
>
> <Files *.inc>
> order allow,deny
> deny from all
> </Files>

Jeg har absolut ingen forstand på hvordan en .htaccess-fil opsættes,
indledes eller afsluttes, men jeg mener at jeg testede .inc på et
tidspunkt hvor jeg lå på en Windowsserver. Det forklarer så også hvorfor
det virker på Localhost hos mig.

--
Philip - http://chartbase.dk

---

Philip Nunnegaard wrote:

>> <Files *.inc>
>> order allow,deny
>> deny from all
>> </Files>
>
> Jeg har absolut ingen forstand på hvordan en .htaccess-fil opsættes,
> indledes eller afsluttes, men jeg mener at jeg testede .inc på et
> tidspunkt hvor jeg lå på en Windowsserver. Det forklarer så også
> hvorfor det virker på Localhost hos mig.

En 'flad' tekstfil, du lægger i webroot. Den _skal_ hedde .htaccess - altså
med punktum først og uden endelse.

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

---

Erik Ginnerskov skrev:

> En 'flad' tekstfil, du lægger i webroot. Den _skal_ hedde .htaccess -
> altså med punktum først og uden endelse.

Så meget ved jeg.
Men sig det samme om en html-fil, og jeg ville misse at en sådan fil er
opbygget af disse elementer (simpelt sat op):

<!Doctype-erklæring>
<html>
<head>
</head>

<body>
</body>
</html>

--
Philip - http://chartbase.dk

---

Erik Ginnerskov skrev:
> Dan Storm wrote:
>
>> Om man så vil sætte serveren op til ikke at sende .inc.php filer er jo
>> så op til en selv (mulighed og kompetence).
>
> Er der tale om en Apache-server, kan det hurtigt indsættes i .htaccess :
>
> <Files *.inc>
> order allow,deny
> deny from all
> </Files>

Man er så afhængig af, at der ikke sker fejl i opsætningen
på webhotellet.

Jeg havde opsat min .htaccess til at behandle html-filer som
php-filer, så jeg kunne bruge php-kode uden at skulle omdøbe
alle filerne. Efter webhotellet lavede om på deres
opsætning, blev filerne ikke længere behandlet som
php-filer, men de besøgende fik i stedet tilbudt at
downloade filerne.

Meget kedelig oplevelse, også selvom jeg ikke havde
adgangskoder liggende i dem.

Efter lidt søgning kunne jeg se, at jeg ikke var den første,
der havde oplevet den slags, så i dag bruger jeg php som
filtype.

--
Mvh. Kim Ludvigsen
http://pc-sikkerhed.dk

---

Lasse Reichstein Nielsen skrev:

> Det er lidt en "fattigmandsløsning" på problemet.

Måske, men den garanterer mod at man laver en tanketorsk en dag.

> En pænere løsning
> ville være at lægge include-filer i et directory der ikke udstilles
> af web-serveren eller at konfigurere web-serveren til ikke at sende
> inc-filer.

Det sidste ville jeg ikke bryde mig om. En konfiguration kan
blive nulstillet ved et uheld.

Jeg har et uskyldigt eksempel der skete for et par dage siden. En
server blev opgraderet fra PHP 4 til PHP 5. Derved nulstilledes
den indstilling der ellers tiillader at man nøjes med <? (har
glemt hvad kommandoen hedder). Resultatet var et hele koden stod
direkte læselig for enhver der blot åbnede usenet.dk. Filen blev
behandlet som en ren HTML-fil.

Hvis noget kan gå galt, så går det galt.

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

---

Bertel Lund Hansen skrev:

> Hvis noget kan gå galt, så går det galt.

og det GØR det, jep.

Meget godt eksempel er dynamiske site-maps. De er vildt smasrte, for de
henter filstrukturen automatisk, men man skal naturligvis sørge for, at
de directories og filer som IKKE skal indekseres bliver sorteret fra.
Jeg havde selv et eksempel, hvor alle includes blev indekseret, pga. en
fejl (som jeg selv lavede). Ikke verdens største militærhemmeligheder på
den side, men alligevel - så jeg måtte lave en test i hver include af,
hvorfra de blev kaldt, så jeg var sikker på, de blev kaldt fra egen
side. Hvis man kan finde dem nu på google, og kalder dem, så får man en
gibberish-meddelelse.

Berlingske havde en meget værre sag. De havde lagt brugeroplysninger ud
til Google hvilket (tror jeg) var pga. forkert opsat site-map. Og de var
f.. ikke meget for at indrømme, det var deres egen fejl..

Så, ja, ting GÅR galt, alene fordi de kan, så filer med vigtigt indhold,
dem tjekker jeg altid hvorfra kaldet kommer. Også selv om jeg om muligt
bruger .asp som endelse, så selve koden ikke kan aflæses ( og .inc.asp
som endelse, hvis det er includes) - udover selvfølgelig at validere på
inputs - GET og POST. Det bedste er at lægge det vigtige uden for
webområdet, men det tillader min hoster så ikke.

Crackeres forsøg på at bryde ind er uendeligt kreative, og Google er en
guldgrube til amatørcrackere såvel som dem, som bare er lidt dovne. Den
indekserer ALT, den kan få fat i, også det, man giver den ved en fejl
(selvfølgelig, selv om man ikke tror det). Man vil blive meget
overrasket. Alene det at ens log bliver indekseret ved en fejl, kan have
konsekvenser - der er mange som har det uden at vide det.


MVH
Rune Jensen

---

Bertel Lund Hansen wrote:


> <?php include "menu.inc.php" ?>

Har du testet positiv funktion på den kode?

Jeg ville skrive den sådan:

<?php include("menu.inc.php"); ?>

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

---

Erik Ginnerskov skrev:

> > <?php include "menu.inc.php" ?>

> Har du testet positiv funktion på den kode?

Ja.

> Jeg ville skrive den sådan:

> <?php include("menu.inc.php"); ?>

Drop overflødige parenteser.

Jeg plejer faktisk at sætte det afsluttende semikolon, men det er
ikke nødvendigt hvis der kun er et statement.

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

---

Den Thu, 19 Feb 2009 10:52:36 +0100 skrev Erik Ginnerskov:

> Det er kun få dage siden, du hakkede på andre for ikke at svare præcis
> på det, der blev spurgt om. Nu kommer du selv med et svar, der er
> 'goddag mand, økseskaft'.

Godmorgen Erik

Jeg vurderede at et præcist svar ikke var muligt i dette tilfælde. Det
Camilla spørger om kræver grundigt kendskab til CSS og PHP for at kunne
udføres. Spørgeren har intet ud af bare at få leveret en "pakkeløsning".

PS.: Erindrer ikke mit "hakkeri"?

---
Karl Erik.

---

Den Thu, 19 Feb 2009 11:45:59 +0100 skrev Erik Ginnerskov:

> Karl Erik Christensen wrote:
>
>> Jeg vurderede at et præcist svar ikke var muligt i dette tilfælde.
>
> Den vurdering ser du ud til at være ret alene om.

Du kan for min skyld mene hvad du vil, men Camilla har jo ikke været inde
siden hun stillede spørgsmålet.
Enten har hun fået det til at fungere, eller også er hun skræmt 1000 km.
væk - vælg selv.

>> PS.: Erindrer ikke mit "hakkeri"?
>
> Jeg gider ikke bruge tid på at finde det frem, så det lader vi ligge.

Nå!

---
Karl Erik.