tisdag 18 mars 2008

Riktlinjer för leverantörer

Jag skrev i mitt förra inlägg att vi haft en hel del problem med våra leverantörer. Jag har fått en hel del positiva och igenkännande kommentarer på detta inlägg. Jag har även fått frågan om det kan vara så illa och om det inte varit småaktörer som gett oss problem? Jag tänker inte hänga ut någon här men det är de stora aktörerna som gett oss flest problem.

Vi har därför skrivit riktlinjer som skall skickas till alla leverantörer innan nya avtal skrivs eller förlängs. På så vis läggs ansvaret på funktionalitet på leverantören och de kan inte i efterhand ändra förutsättningarna. Om leverantören inte kan uppfylla alla nedanstående krav så innebär det inte per automatik att vi säger nej till tjänsten. Men vi bör då ta en diskussion internt innan vi accepterar. Om inte annat så vet vi vad vi ger oss in på.

Det ligger i vårt intresse att fler än oss ställer dessa krav så därför publicerar jag dem här. Vi vill gärna ha synpunkter på dessa och förslag på mer saker som bör tas upp.

Observanta läsare märker att jag inte skriver så mycket om Flash och hur det skall/bör användas på hd.se. Jag tänkte nämligen använda hela nästa blogginlägg till det.

Nu över till riktlinjerna:
1 Sammanfattning
Vi på hd.se tycker att webbstandarder är mycket viktigt och allt som läggs ut på vår sajt skall därför validera enligt http://validator.w3.org/. För att det skall fungera smidigt så kräver det att materialet vi får in följer våra riktlinjer. Det är också viktigt att olika leverantörers kod inte "krockar" med varandra, att säkerheten upprätthålls, att sajten fungerar för alla oavsett operativsystem och webbläsare.

Eftersom man kan leverera material på flera olika sätt och format så har vi gjort en sammanställning på hur vi vill ha det.

2 Plattform
2.1 Klientplattform
Vi strävar efter att alla lösningar skall fungera oavsett vilken webbläsare eller operativsystem som används. Därför skall lösningarna vara testade från följande versioner till senaste;

Internet Explorer 6
Safari 2.0 (build 412)
Firefox 2.0

Uppfylls kravet? Ja / Nej / Inte tillämpbart

2.2 Serverplattform
Vi använder följande mjukvaror på hd.se:
Linux
Apache 2.2
MySQL 5.0 med teckenkodningen UTF-8 (till skillnad från standard ISO-8859-1 aka latin1)
PHP 5.0 med register_globals, magic_quotes_gpc och safe_mode deaktiverat

Se även styckena under 3.5.1 Databasbaserade tjänster och 3.5.2 PHP för mer detaljerad information.

Om leverantörens lösning behöver installeras på hd.se:s servrar bör den vara anpassad för att fungera med ovanstående.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

3 Drift
3.1 Leverans
Vi tar helst emot feeder av XML via FTP eller HTTP (tex RSS). Iframes som vi "bara" länkar in ger oss oftast mer problem än om vi får en feed med rådata. Om ni kräver specfik layout såsom logos och typsnitt så föredrar vi ett avtal om hur det skall se ut.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

3.2 Felhantering
Leverantörens lösning måste hantera fel på ett för besökaren användarvänligt sätt. Det är till exempel inte acceptabelt att använda Javascript's alert() vid fel.

Om en besökare helt saknar, eller har en för gammal version, av en plugin (t.ex. Flash) eller webbläsare så ska detta meddelas på ett, för besökaren, hjälpsamt sätt med information och länk dit senaste versionen kan hämtas.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

3.3 Uppdateringar
Om det blir problem med nyare versioner av webbläsare, Flash etc så är det leverantörens ansvar att korrigera detta då det oftast uppstår när produktionssättet inte följt riktlinjer för webb och program-standard.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

3.4 Övervakning
Alla leverantörer svarar själva för övervakning av att deras system fungerar. Om problem uppstår skall hd.se meddelas omedelbart enligt överenskommelse. T.ex. via e-post eller telefon.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

3.5 Säkerhet
Det är leverantörens ansvar att se till att produkten inte äventyrar datasäkerheten på sajten.

3.5.1 Databasbaserade tjänster
Tjänster som använder en databas måste se till att skydda sig mot SQL-injections. Det ska framgå vilka privilegier (SELECT, INSERT, ..) databasanvändaren behöver för att applikationen ska fungera. Se MySQL's dokumentation över privilegiesystemet för mer detaljer.

Vid leverans av tabelldefinitioner och eventuell tabelldata så ska dessa levereras som en SQL-dump, förslagsvis UTF-8 kodad även om vi kan hantera standardteckenkodningen ISO-8859-1 aka latin1.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

3.5.2 PHP
Tjänster som behandlar någon form av indata från besökaren, både i form av inparametrar och eventuell information i kakor, måste se till att dessa har ett förväntat och acceptabelt format. Obehöriga ska inte kunna komma åt filer på servern, databasinformation som inte avsågs från början eller kunna exekvera kod eller kommandon på servern eller på i databasen.

Vanliga problem är till exempel SQL-injections, Cross Site Scripting (XSS) eller remote file inclusion.

Hos oss är följande avstängt:

PHP safemode
Register_globals
Magic_quotes_GPC -- applikationen måste själv sköta escapning av indata från HTTP GET/POST eller kakor.
Applikationen ska ur ett säkerhetsperspektiv följa best practices redan från början och det är leverantörens ansvar att se till att dessa följs. Vid behov kan vi ge tips på det vi känner till. Data som hämtas från request parametrar (t.ex. vid HTTP GET eller POST), kakor, filer eller databasposter ska alltid escape's innan de används.

Data som hanteras i samband med SQL-frågor ska escape'as med mysql_escape_string() eller metoden mysqli::escape_string() om man använder den objektorienterade varianten av MySQL API:et i PHP.
Data från databasposter eller filer som skrivs ut i HTML-dokument ska alltid kodas med htmlspecialchars(), både för att HTML-koden ska blir korrekt och av säkerhetsskäl.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

4 Format
4.1 HTML
Vi använder XHTML på hd.se och är väldigt noga med att den XHTML som finns på vår sajt är korrekt och validerar enligt W3C (http://validator.w3.org/).

Leverantörens HTML-kod skall validera enligt minst "XHTML 1.0 Transitional" standarden men vi ser gärna att "XHTML 1.0 Strict" används.

Om HTML levereras från leverantörens server ser vi gärna att den komprimeras (i Apache med mod_gzip/mod_deflate) innan den skickas för att minska datamängden som hämtas, till fördel för besökare med långsammare uppkopplingar.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

4.2 Teckenkodning
Teckenkodningen vi använder på hd.se är UTF-8. Den används på webben, internt i våra system och vid kommunikation med externa system.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

4.3 CSS
Om selektorer och klasser används så ska dessa ha ett prefix, gärna baserat på företags/tjänstens namn så att de inte krockar med vår eller andra leverantörers CSS. CSS:erna skall ligga i egen fil och kunna kontrolleras av HD.

Då en leverans resulterar i html-kod på hd.se är det ett krav att den ytterst omslutande taggen i html-portionen är identifierad med ett väl beskrivande och särskiljande ID-attribut.

Exempel på bra id´n som definierar både leverantören och tjänsten:

omxStockTicker
sjTimeTable
nordeaIntrRates

Uppfylls kravet? Ja / Nej / Inte tillämpbart

4.4 Javascript
Alla variabler ska defineras med keywordet var innan de används. Exempel: 'var debug = false;'. Användning av variabler som inte definerats innan de används gör javascript långsammare.

Globala javascript variabler och funktioner ska ha ett prefix, gärna baserat på företagets/tjänstens namn, så att de inte krockar med våra eller andra leverantörers dito. Inneslut helst hela javascriptfunktionaliteten i en, alternativt några, omslutande variabler för att komma så nära konceptet "scoope" som möjligt.

Vi ser gärna att javascript så långt det är möjligt läggs i en extern fil och hämtas in på de ställen de behövs. På det viset kan webbläsaren cacha scriptet och besökaren behöver inte hämta hem samma javascriptkod för varje sidvisning.

OBS! Vi använder oss redan av vissa javascriptbibliotek som t.ex. SWFObject för att hantera Flash. Det kan finnas tillfällen då det kan utnyttjas utan att besökaren ska behöva hämta hem leverantörens bibliotek också. Kontrollera med oss om ni är osäkra på vad vi använder!

Om javascript är avslaget hos klienten så bör det finnas en alternativ lösning och i värsta fall ett läsbart "felmeddelande".

Uppfylls kravet? Ja / Nej / Inte tillämpbart

4.5 Kakor (cookies)

Eventuella kakor som sätts bör ha korta namn och värden. Lagra inte information i kakorna som annars skulle kunna ligga i en sessionsvariabel (eller databas) på servern. Stora kakor i kombination med många anrop till webbservern påverkar prestandan negativt då kakorna måste skickas med varje gång. Många besökare har en liten bandbredd uppströms.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

4.6 Filformat och Plugins
Vi accepterar inga andra webbläsarplugins än Flash. Det skall fungera från version 9 till den senaste.

Uppfylls kravet? Ja / Nej / Inte tillämpbart

5 kommentarer:

Pelle Sten sa...

Snyggt.

Anonym sa...

Jag föreslår även att ni lägger till att lagras några lösenord ska dessa lagras krypterat..

Anonym sa...

Cross Site Scripting (XSS) borde vara ett allmänt krav inte ett php-krav. Används oftast för att få reda på en besökares sessions-id så de kan ta över dennes inloggning. Å detta kan de göra oavsett plattformsval.

Anonym sa...

Svarstider?
Cachning?
Lasttester?
Automatiska enhetstester?
Dokumentation? Drift, utveckling, användar..
Api för er inloggning?
Engelskt språk?

Ett par av dem beror på om ni köper in en produkt ni ska ha inhouse och själva vidareutveckla eller om de bygger och driftar.

Jonatan sa...

Grym grej! Tack för en toppenbra sammanställning.