This is fine for the beginning amateur, but professionals should always get this right.

What happens when you don’t do this

If you are very lucky, you will have a lot of extra work and more complicated code. If you are less lucky strange things will happen on your website. Maybe “2<3″ is displayed as “23″ or “don’t” is displayed as “don\’t”. Maybe it’s even saved like that in the database, which just makes it much harder to fix.

But worst case is a gaping security hole. Do one little thing wrong, and you can get serious security vulnerabilities like XSS and SQL injection.

What is layers

Any non-static website has layers. It’s just a question of how many, and if you are using them correctly. To make a simple blog you need at least three:

1. The presentation (HTML, CSS etc.)
2. The application (maybe written in PHP)
3. A database (like MySQL)

A layer should only know about what is above it, and what is below it. In this extremely simple scenario, the HTML knows about the PHP (filenames for the links etc.), but should never know about the database (table names and certainly never ever login information). And SQL statements (or even snippets) should NEVER get more than one layer away from database layers.

Usually there is many more layers in the application part to simplify things. Maybe there is a layer for translating pretty urls to actual PHP filenames. And there should be a “database abstraction layer”, which makes database access look the same no matter which database you use.

En example of how even abstraction layers that hardly adds any features are useful: It adds flexibility. With a good database abstraction layer, you can change the entire database (maybe from MySQL to PostGreSQL) without changing your actual application. You just edit the abstraction layer, which sits between the application and the database. The advantages becomes clearer further down.

In this article I will only talk about a few layers, enough for most simple web-projects. But the idea is the same with any amount of layers. I will use:

1. The presentation (HTML, CSS etc.)
2. The application (maybe written in PHP)
3. Database Abstraction Layer
4. A database (like MySQL)

My recommended solution

When the user performs an action (like a search), data from the user (for example search terms) travels through the layers, probably all the way to the bottom, and then results (for example search results) travels all the way back up, possibly including the original data.

Here comes the important part:

When data moves from one layer to the other, make sure all necessary conversions are done correctly, and preferrably automatically.

When data moves from the browser to your application, you will probably get it as normal plaintext. So far so good.

Then you transfer the data to the database. The database interpretes certain characters specially, like percent, underscore and apostrophe. The amateur is tempted to fix this with search-and-replace, and will often do this the wrong place so that the fix ends up in places outside the database.

This is a task for the database abstraction layer. My favorite way is parameterized statements. A simple example:

result = db.getAll("SELECT id, name FROM students WHERE name=?", name);

The questionmarks gets replaced with the parameters after the query.

The variable db containts an object from the database abstraction layer. Which you may have made yourself, maybe one provided by the system you use (PHP has several), or as I prefer – a simply one build on top of something good someone else has made.

The results from the database should be in plaintext. No special handling of any characters, special to SQL, HTML or any other technology. Any layer should only know about the layer above and below, and the HTML and browser is far above the dabase and database abstraction layer(s).

Now you have the input and the result from the database, and it’s time to display them. But data is sent to the browser in HTML format, not plaintext. So transferring data from the application to the presentation layer, means translating from plaintext to HTML.

There are tons of ways to do that, depending on the framwork you are using. Here’s a very primitive way of doing it in PHP:

<p>
Search terms: <?=toHTML($terms)?><br />
Results: <?=$result_count?><br /><!-- No need to escape, this is numeric -->
</p> 

In this primitive example, you need to remember “toHTML()” every time you print out text, which is a weak spot. In some systems it takes extra code to NOT encode it in HTML.

The toHTML()-function will replace < with &lt; etc. Maybe it inserts <br /> at the end of lines, but then you should check that the search terms doesn’t have more than one line. Maybe you should check for that anyway. If it’s a comment for all users to see, maybe you want some extra checks here. like collapsing 500 newlines in a to two. Maybe like this: <%=toHTML(sanitize($terms))%>

But why not sanitize it while getting it from the browser, so we get sane data? Well, it is a good time to check for very bad input, like binary data. But I like to have the original input in the database. That is always a good thing, for example if you change something in how you display your data. Maybe you want to change how you handle newline characters. Maybe you have improved your sanitizing method.
With this method you just change your code, and you’re done. If you change the data before you put it in your database, you will need to change your old data. This can be very complicated, sometimes impossible. (For example if a bug removes data.)

Summary

• Know that you have layers, and which ones
• Insert abstraction layers when they add value
• A layer can only know about the layer directly above or below
• When data moves from one layer to another, convert it accordingly
• Do the conversion in a common place so you only have the code once, and maybe even in a way so you don’t need to remember to do it every time

Doing this the right way makes simple code, pretty results and solves most security issues.

1. Den korte udgave
2. Sagen indtil nu
3. Mine kommentarer til afgørelsen
4. Hvad skal vi andre gøre?
5. Andre bemærkninger om Orango ApS
6. Relaterede links

Den korte udgave

Peter Veileborg har haft domænet orango.dk i 9 år, og bruger det som sin online identitet, da han er kendt under navnet “Orango”. Det domæne bliver nu taget fra ham af domæneklagenævnet, fordi firmaet Orango ApS (stiftet i januar i år) bedre kan lide det, end deres nuværende orango.nu. Hvordan pokker kan de få lov til det? Hvad skal vi andre gøre for ikke at blive udsat for det samme?

…og så den lange. ;-)

Sagen indtil nu

Januar 2000: Peter Veileborg er kendt under navnet Orango, og vælger at registrere domænet orango.dk til email. Et par år senere laver han også en simpel hjemmeside.

Januar 2009: Firmaet Orango ApS stiftes, og de markedsfører sig på domænet orango.nu.

Lidt senere i 2009: Orango ApS synes det er problematisk, at kunder leder efter hjemmesiden på orango.dk i stedet for orango.nu.

Marts 2009: Orango ApS forsøger at købe orango.dk af Peter Veileborg for 500 kr., men Peter siger at domænet ikke er til salg. Han gør dog opmærksom på at en større pris kan få ham til at genoverveje.

Maj 2009: Orango ApS klager til domæneklagenævnet.

November 2009: Domænet orango.dk bliver frataget Peter Veileborg og overdraget til Orango ApS, med effekt fra 4. december 2009.

Mine kommentarer til afgørelsen

Helt overordnet synes jeg afgørelsen ikke bare er forkert, den er uretfærdig, en hån mod danske forbrugere og på dette punkt er jeg flov over at være dansker. Det styrker den tendens jeg oplever flere og flere brokke sig over: Firmaer er vigtigere i Danmark end borgerne.

Her er mine kommentarer til Orango ApS’s klagepunkter: (citater er fra afgørelsen (PDF))

Klageren har gjort gældende,

• at klageren benytter betegnelsen ”Orango” som selskabsnavn og varemærke,

Her står de to parter lige, de har samme navn.

• at klageren alene henvender sig til kunder på det danske marked,

Her står de to parter lige, da Peter Veileborg er dansker, og har lige så stor tilknytning til “.dk”.

• at klageren derfor har en væsentlig interesse i at kunne gøre brug af domænenavnet ”orango.dk”,

Det har Peter Veileborg også. Efter 9 år er det en del af hans “online identitet” – folk er vant til at kontakte ham på den adresse, og han er formentlig registreret i mange systemer med den. Så stadig lige.

• at der ikke tidligere var nogen hjemmeside på domænenavnet ”orango.dk”,

Jeg kan ikke se hvordan det kan være et argument. Et domænenavn bruges til meget andet end hjemmesider. I dette tilfælde er der mindst tale om email, og at det er hans online identitet. I øvrigt har der teknisk set været en hjemmeside siden 2002, og dermed 7 år længere end Orango ApS har eksisteret. Hjemmesiden burde skubbe afgørelsen en anelse til Peter Veilborgs fordel.

• at den hjemmeside, som indklagede efter klagerens henvendelse har etableret under domænenavnet ”orango.dk”, ikke har nogen særlig tilknytning hertil, og derfor kan flyttes til et hvilket som helst andet domænenavn,

Det er korrekt, men hjemmesiden er jo heller ikke hans primære formål med domænet. Det primære formål er email, og kan være meget vanskeligt at skifte email-adresse.

• at indklagede har tilkendegivet at ville sælge domænenavnet ”orango.dk” til klageren, hvis prisen var tilstrækkelig høj,

Jeg har læst deres kommunikation igennem, og to ting er meget tydeligt for mig: For det første er domænet ikke til salg, og har aldrig været registreret for at sælge det igen. For det andet kender han er han klar over at han (som i stort set alle tilfælde) er klar til at sælge, hvis prisen er høj nok. Det betyder sandsynligvis at der skal kompenseres for ulemperne (hvilket i sig selv er noget mere end de 500 kr. de bød), plus et beløb som gør det interessant at indvolvere sig.

• at domænenavnet ”orango.dk” derfor bør overføres til klageren.

Jeg fik det til præcist nul gode grunde.

I afgørelsen har nævnet en række bemærkninger, dvs. begrundelser for afgørelsen. Der snakker de bla. om god skik. Jeg undrer mig over hvad Peter Veilborg kan have gjort, som er imod god domæneskik. Det er Orango ApS der har valgt at benytte et firmanavn, hvor .dk-domænet ikke var ledigt. Da de valgte at benytte domænet orango.nu kunne de have valgt at navngive firmaet Orango.nu ApS. I betragtning af at det er et internet-baseret firma er det overhovedet ikke en upraktisk løsning.

Derefter de at domænet benyttes til email, online identitet og hjemmesiden. Derefter snakker de om at hjemmesiden let kan flyttes, og ser bort fra de to andre punkter.

På denne baggrund er det klagenævnets opfattelse, at det har en langt større interesse og værdi for klageren end for indklagede at kunne gøre brug af domænenavnet ”orango.dk”, og at indklagede, for hvem dette har været kendeligt, som følge heraf har optrådt i strid med god domænenavnsskik ved at nægte at afstå dette domænenavn til klageren på rimelige vilkår.

Hvis Orango ApS har større interesse end Peter Veilborg, så er der udelukkende tale om entusiasme. På nuværende tidspunkt skulle det ikke overraske mig om en helt tredje har endnu større interesse i domænet, da det nu har været omtalt i rigtigt mange medier.

Hvis domænet har større værdi for Orango ApS end Peter Veilborg, er det udelukkende fordi Orango ApS har båret sig uheldigt ad. Jeg kan ikke se hvorfor Peter Veilborg skal bøde for dette.

Som jeg ser det har han nægtet at afstå domænenavnet på urimelige vilkår, hvilket er ganske forståeligt. Selvfølgelig skal have en ordentlig kompensation, hvis domænet skal overdrages. Jeg mener at han viste tydeligt nok, at det var et spørgsmål om en realistisk kompensation. Og jeg mener at Orango ApS viste tydeligt nok, at det var de ikke interesseret i at give. Og de var da slet ikke interesseret i at betale et beløb, som bare minder om den værdi, de tilsyneladende mener domænet har for dem. Jeg har en fornemmelse af at de 500 kr. handlede mere om at have et argument til klagen, end at de reelt var parate til at købe domænet.

Man kan argumentere for at Orango ApS blot har benyttet sin ret til at få sin sag afprøvet ved et nævn, og at det er nævnets ansvar at komme med en retfærdig afgørelse. Men på den anden side er det ikke alt man har ret til at gøre, som er moralsk i orden.

Hvad skal vi andre gøre?

Ud over at det er synd for Peter Veileborg, så er jeg da også nervøs for mit eget domæne. Og mine venners domæner. Og stort set alle andre .dk-domæner, som bliver brugt privat. Tilsyneladende er .dk-domæner til privat brug noget man har, indtil et firma får lyst til at overtage. Det er da en særdeles bekymrende tanke.

Jeg identificerer mig vane-mæssigt ved at modtage en mail. Hvis jeg mister mit domæne, kan jeg ikke identificere mig over for et hav af tjenester. Det vil være et kæmpe problem for mig. Faktisk vil den nye domæne-ejer have overtaget meget af min identitet, en ting som normalt er ulovligt.

Tilsyndeladende er vi nødt til at skifte domæne nu, mens vi har muligheden for at gøre det i vores eget tempo.

Andre bemærkninger om Orango ApS

Alle laver fejl, og selv grove fejl skal man være parate til at tilgive. Men inden du overvejer at handle med Orango ApS, bør du også vide følgende.

1) Deres logomand er ikke noget de selv har lavet. Hvor figuren oprindeligt stammer fra ved jeg ikke, men den kan bla. købes hos iStockphoto, og bliver brugt mange andre steder. I øvrigt virker deres tilpasninger (først og fremmest hovedet udskiftet med et logo) nu heller ikke helt professionelt. Det er tydeligvis ikke lavet i 3D, men med simpelt klippe/klistre i et Photoshop-agtigt program.
Det er da flovt, at et firma som lever af at lave design, ikke kan lave sit eget uden at basere det på et købt standard-produkt.

2) I skrivende stund har deres hjemmeside et åbenlyst og amatøragtigt sikkerhedshul, en såkaldt XSS (Cross-Site-Scripting)-fejl. Klik på linket (og bladr ned i bunden) for at teste om hullet stadig er uændret, eller se screenshot herunder.
Konsekvensen er fx. at jeg kan lave et specielt link til orango.nu, som teknisk set giver dig en side fra deres server, men som jeg modificere helt som jeg har lyst. Hvis der fx. er login-mulighed, kan jeg ændre systemet så folks brugernavn og kodeord bliver rapporteret til mig, uden de selv kan se der sker noget usædvanligt.
Dette er utroligt amatøragtigt, for et firma som ellers burde leve af at have styr på den slags.

Klik for større billede

3) Jeg har kigget lidt på den første side jeg kunne finde, som de har lavet. Det er langt fra det værste jeg har set, men det bærer meget præg af at være baseret på kode de har fundet rundt omkring på nettet, i stedet for at lave tingene selv. Det er ikke uacceptabelt, men det er absolut heller ikke professionelt.

3a) Orango ApS har lavet en hjemmeside for Warmdal Blomster. Butikken har fået en meget rosende anmeldelse flere steder (MitKBH, Alt om København, the copenhagen guide m. fl.) af “KasperFP”. På sin egen blog skriver KasperFP stolt om at han har lavet siden, at han er medejer af Orango ApS og at butikken tilhører hans svigerforældre. Der er ikke noget ulovligt i at rose et produkt uden at fortælle at man er dybt indvolveret i det, men det betragtes generelt som meget umoralsk og upopulært.

Og så selvfølgelig de åbenlyse ud fra denne sag:

4) De har ikke sans for håndtering af domænenavne

5) De har intet imod at trumle den lille mand ned, for at få sin vilje. Heller ikke selv om der er andre muligheder der er lige så gode, og som ikke går ud over andre.

Så kort sagt: De er amatøragtige, inkompetence og umoralske. Og det vil jeg egentlig fastholde, uanset hvad de har lavet af gode ting.

Relaterede links

• Om kampen: Orango-Tilbage
• Blogindlæg: Danske TLD domæner er ikke længre sikre for privatpersoner.. Go EURid!
• Blogindlæg: Ejeren af domænet orango.dk skal overdrage det til orango.nu
• Nyhedsartikel: Domæne-ejer mister navnet efter ni år
• Underskriftindsamling: Domænefriheden tilbage – tak!
• Facebook gruppe: orango.dk skal forsat ejes af Peter Veileborg
• Klip fra Dr Update: Smidt ud fra egen hjemmeside

UPDATE 2009-11-22: Tilføjet link til blogindlægget “Ejeren af domænet orango.dk skal overdrage det til orango.nu”
UPDATE 2009-11-22: Tilføjet punkt 3a i listen over hvad Orango ApS ellers gør forkert.
UPDATE 2009-11-22: Tilføjet diverse illustrationer. Jeg skulle mene at jeg overholder ophavsretsloven mm. under citater, parodier og illustration. (Det man i den amerikanske udgave kalder “fair use”.)
UPDATE 2009-11-22: Overstreget link til MitKBH, da jeg opdagede at han der indrømmer sin relation. Ret skal være ret.
UPDATE 2009-11-29: Tilføjet link til “Orango-Tilbage”

1. Log ind
2. Gå ind på den side som gør det, dit script skal gøre. Fx. for at tilføje en record, skal du gå ind på den side hvor du angiver detaljerne
3. Ret formens method fra POST til GET. Det kan man ikke med en helt almindelig browser, men med Firebug er det nemt, med Web Developer er det endnu nemmere. (De er begge plugins til Firefox.) Chrome kan vist gøre det uden plugins.
4. Udfyld og submit
5. Kopier urlen du nu er inde på
6. Dit script kan nu tilpasse data i urlen, og blot downloade den.

Eksempel – Gmail

Hvis man vil bruge Gmail på dit eget domæne skal du tilføje et hav af MX-records til dit domæne. Det skal man ikke gøre på ret mange domæner før det bliver kedeligt. (Jeg begyndte at kede mig inden jeg blev færdig med et første domæne.)

I Ubuntu Linux brugte jeg dette simple bash-script (kræver at curl er installeret):

#!/bin/bash
USER=myplacedk
PASSWD=god
DOMAIN=myplace.dk
HOST=$DOMAIN

function addMX() {
 pref=$1
 exchanger=$2
 curl --silent "https://ssl.gratisdns.dk/editdomains4.phtml?user=$USER&password=$PASSWD&user_domain=$DOMAIN&action=addmxrecord&host=$HOST&exchanger=$exchanger&preference=$pref&button=Tilf%F8j+MX+recorden" > /dev/null
}

addMX 10 aspmx.l.google.com &&
addMX 20 alt1.aspmx.l.google.com &&
addMX 20 alt2.aspmx.l.google.com &&
addMX 30 aspmx2.googlemail.com &&
addMX 30 aspmx3.googlemail.com &&
addMX 30 aspmx4.googlemail.com &&
addMX 30 aspmx5.googlemail.com

Scriptet giver ingen statusmeddelelser, så kig selv om de er dukket op som de skal.

Eksempel 2 – Google Chat

Hvis man vil bruge Google Chat på sit eget domæne, og chatte med folk på et andet domæne, skal der en masse SRV-records til. Dem tilføjer jeg sådan her:

#!/bin/bash
USER=myplacedk
PASSWD=god
DOMAIN=myplace.dk
HOST=$DOMAIN

function addSRV() {
 host=$1
 pref=$2
 weight=$3
 port=$4
 exchanger=$5
 curl --silent "https://ssl.gratisdns.dk/editdomains4.phtml?user=$USER&password=$PASSWD&user_domain=$DOMAIN&host=$host&exchanger=$exchanger&preference=$pref&weight=$weight&port=$port&action=addsrvrecord&button=Tilf%F8j+SRV+recorden" > /dev/null
}

addSRV _xmpp-server._tcp.$HOST 5 0 5269 xmpp-server.l.google.com
addSRV _xmpp-server._tcp.$HOST 20 0 5269 xmpp-server1.l.google.com
addSRV _xmpp-server._tcp.$HOST 20 0 5269 xmpp-server2.l.google.com
addSRV _xmpp-server._tcp.$HOST 20 0 5269 xmpp-server3.l.google.com
addSRV _xmpp-server._tcp.$HOST 20 0 5269 xmpp-server4.l.google.com
addSRV _jabber._tcp.$HOST 5 0 5269 xmpp-server.l.google.com
addSRV _jabber._tcp.$HOST 20 0 5269 xmpp-server1.l.google.com
addSRV _jabber._tcp.$HOST 20 0 5269 xmpp-server2.l.google.com
addSRV _jabber._tcp.$HOST 20 0 5269 xmpp-server3.l.google.com
addSRV _jabber._tcp.$HOST 20 0 5269 xmpp-server4.l.google.com

Update 2009-11-07: Tilføjet eksempel til Google Chat

Normal

This is a typical spider web. This is the goal, what you should compare the other images with.

Marijuana

This spider was given marijuana (or “hash”) before making the web. Marijuana makes you slow and makes it hard to concentrate. The spider started just fine, but then it got lazy.

Benzedrine

Benzedrine made this spider active. So active, it forgot to plan anything.

Chloral Hydrate

Chloral hydrate is (among other things) a sedative. This poor spider started nicely, and probably fell asleep.

Caffeine

This is the interesting part. This is what happens when you get too much caffeine. No planning, no system, worthless. Like the sedated spider, it never got to the part with the spirals. Now let me ask all you software developers like me out there: Do you really want to create software, with large amounts of caffeine in your body? And everybody else: Do you want to use software created like this?

This experiment was invented in 1948, but these images are from a similar experiment performed by NASA in 1995.

Source: Wikipedia - Effect of psychoactive drugs on animals

And by the way:

In large amounts, and especially over extended periods of time, caffeine can lead to a condition known as caffeinism. Caffeinism usually combines caffeine dependency with a wide range of unpleasant physical and mental conditions including nervousness, irritability, anxiety, tremulousness, muscle twitching (hyperreflexia), insomnia, headaches, respiratory alkalosis, and heart palpitations.

Wikipedia – Caffeine

Så er det endnu engang tid til en ny hjemmeside. Alt hvad der stadig er aktuelt fra den gamle vil blive flyttet, men nogle sider forsvinder.