pellesoft.se

Den perfekta inloggningen #1

Postad 2002-11-21 av Pelle Johansson i sektionen ASP.NET, C#, Okategoriserat med 3 Kommentarer | Läst av: 9819, Betyg: 87%

Förord

Det finns väldigt många sätt att bygga regler och hantering på hur inloggningar skall göras så detta är en sammanställning av de erfarenheter jag har utifrån att bygga hantering för inloggningar. I dessa exempel har jag valt att använda SQL-server som databas och kunna nyttja lagrade procedurer, men det är inte svårt att skriva om detta till vanliga sql-satser som även kan köras för andra databaser. Innan vi kan börja så måste vi gå igenom lite förutsättningar som skall uppnås. Om man skulle se detta som ett helt projekt för att bygga på säkerhet så måste vi tänka igenom hur vi skall kunna uppnå en hög säkerhet, dynamisk hantering och funktioner som gör att det blir så enkelt som möjligt för användaren. En regel för en bra hantering rörande inloggning är att användaren inte skall behöva tänka på något annat än att ange sitt lösenord, resten skall ske i bakgrunden.

Innehåll

» Vad krävs?
» Vad behöver vi för funktioner?
» Slutord
» Användare
» Kompletterande fält i tabellen användare
» Roller
» Några ord om bitwise
» Lägga till en egen datatyp
» Summering

Relaterade artiklar

» Den perfekta inloggningen #2
» Den perfekta inloggningen #3

En komplett inloggningshantering

Det är många som frågat hur man gör en inloggning och arbetar med att försöka få en sajt säker på alla sätt och vis. Denna, eller rättare sagt troligen dessa kurser kommer att innefatta information och utbildning om hur man kan göra för att skriva ett säkert system.

Vad krävs?

För att kunna göra precis som jag föreslår så behövs en webbserver med IIS, företrädesvis 5.0 som finns i Windows 2000 Server samt SQL Server 7 eller senare. Jag kommer dock inte ta hänsyn till designen genom att skriva webbsäkra html-sidor för att kunna presenteras på samma sätt i alla de förekommande webbservrar som finns på marknaden. För att kunna följa denna kurs behöver du goda kunskaper i asp samt databaser. Jag kommer att behandla vissa områden lite ytligt i förhoppning om att du troligen redan vet hur man gör, och saknar du de kunskaperna så försöker jag referera till andra artiklar här som kan hjälpa dig förstå dess innebörd.

Vad behöver vi för funktioner?

Om vi skall försöka specificera vad som egentligen behövs för att kunna göra en bra hantering, och då menar jag en total hantering – inte endast en inloggningsruta utan även de kringrutiner som behövs för att få ett stabilt och lätthanterligt system. Nu tittar vi på några av de sektioner som vi behöver ta hänsyn till.

Inloggningssida - På inloggningssidan det lätt tillgängligt finnas information om lösenordet slarvats bort. Det bör även framgå hur man registrerar sig och vad det innebär för besökaren. Ett val för automatisk inloggning bör föreslås.
Glömt lösenord – Med en tjänst kan man få sitt lösenord utskickat via e-post.
Automatisk inloggning – Tillåt användaren att kunna göra en automatisk inloggning för att underlätta återbesök. Detta gäller även när sessionen upphör.
Registrering – Innan man kan logga in måste man registreras upp med ett konto. Efter att registreringen gjorts så kommer användaren få ett välkomstmail samt information om inloggningsuppgifter. Registrering är en oerhört vital del vid och därför kommer jag gå in på detta mer detaljerat senare.

Vi skall även tala om säkerhetsaspekter för varje sida som användaren besöker. Jag kommer även beröra möjligheten att tillåta användare att delas in i olika roller för att kunna uträtta olika mycket på din site. Vi kommer således att behandla dessa fem huvudpunkter, nämligen registrering, inloggning, återbesök, säkerhet och slutligen rättigheter.

Slutord

Innan vi nu går vidare så vill jag berätta att jag kommer ta en del i taget men varefter vi kommer längre och längre in i vårt system så kommer påsen att knytas ihop mer och mer så försök att läsa från början till slut för att få ett bra grepp om hur jag tänkt mig systemets gång. Jag kommer under kursens gång gå in på flera detaljer och förklara olika tekniker som du kan använda dig av. Om du sedan vill nyttja detta eller inte är upp till dig.

Användare

Nu har jag berättat vad vi kommer att behandla så nu är det dags att börja sätta oss in i hur vi kan strukturera upp ett tabellverk för att lagra, söka och luta oss mot när vi sedan börjar skriva programkod.

Vi börjar med att skapa får huvudtabell, nämligen tabellen för användare. Här ser du ett utkast på hur denna tabell skulle kunna se ut.

Ovan ser du en tabell som jag kallat användare, jag ersätter ä med ae, samt ö med oe och å med aa – detta för att undvika åäö men ändå hålla sig med svenska ord för det kan underlätta då denna kurs är skriven på svenska. Om vi tittar igenom dessa kolumner så har användarid fått primary key, tillåter inte att fältet är tomt, samt att den har egenskapen auto increment – vilket innebär att för varje post som adderas så ökar användarid med 1 för var gång.

Vi har för och efternamn som jag valt att separera dels för att jag själv oftast använder förnamnet som presenteras vid vissa sammanhang, exempelvis då du tilltalar medlemmen direkt. Ett exempel kan vara ”Välkommen Pelle”. I stället för att behöva bryta isär namnet för varje gång detta presenteras så är det en enkel lösning.

Vi har epost som givetvis är vitalt för oss. Utan denna kan vi inte meddela det lösenord som användaren fått. Vi kan inte heller kommunicera med annat material och tjänster som vi kan tänkas erbjuda användaren.

Fältet lösenord använder vi för att lagra ner det lösenord som användaren tilldelats och skall använda för att kunna logga in.

Slutligen så har jag valt att ha ett fält som är ett tecken, automatisk inloggning. Detta fält avser jag att skriva J eller N beroende på om användaren vill göra en automatisk inloggning eller inte. Mer om dessa fält kommer vi att prata om senare. Men innan vi går vidare vill jag ta tillfället i akt och fortsätta bygga på denna tabell något.

Kompletterande fält i tabellen användare

Vi har nu dom mest vitala fälten men som jag nämnde tidigare. Det finns mer information som du säkert vill ta reda på. En regel som jag alltid säger till kunder är att när besökaren väl registrerar sig så har du inga fler chanser att få information. Detta är givetvis en sanning med modifikation – speciellt här på pellesoft då många är väldigt duktiga på att komplettera i efterhand. Men ha detta alltid i åtanke när du bygger en registreringssida, ”du får aldrig 2 chanser”.

Det jag skulle vilja komplettera med är lite beroende på vad hemsidans syfte är. Om det är relevant med ålder, kön, yrkesroll, var man bor, om man har ICQ och mycket annat kan diskuteras. Om vi tar pellesoft som exempel så finns en community. Därför kan det vara intressant med ålder. Lika viktigt är det när någon skriver i forumet om hjälp. Genom att se den frågandes ålder kan man också avgöra hur man kan svara. En yngre person får man ta mer hänsyn till än en äldre osv. Vad du väljer är viktigt för just dig får du bestämma, men jag understryker återigen att tänk igenom noga vad du vill ha ut för information.

Det jag vill lägga till i detta fall är främst om användaren tillåter att få mail. Genom att ställa denna fråga kan du aldrig anklagas för att skicka ut spam. Så vi kompletterar med ett sådant fält. En annan sak jag anser vara viktigt, i alla fall för denna kurs är ett fält för användarens roll på hemsidan.

Nu har vi dom mest elementära fälten som behövs för att kunna hantera en användare. Egentligen hade jag velat lägga till i vilken stad man bor, men att hålla en tabell aktiv för alla städer är inte det lättaste. Speciellt inte med tanke på om man skall låta användaren själv få skriva staden. Tänk bara hur många tänkbara stavningar man kan få på Göteborg om man skriver slarvigt, då blir det svårt att gruppera användare per stad och massor av manuellt arbete för att rätta upp detta löpande.

Bättre är då att ha en lista med alla städer som man kan presentera för användaren. Men även denna måste underhållas så det blir arbete hur man än gör. Det går att hämta hem kompletta listor från Internet men jag har inte funnit någon komplett lista ännu. Posten har sina egna registrer och det finns även kund/säljstöds system som har denna information som du kanske kan exportera. Du får prova dig fram och se om du vill ha denna funktionen. Att kunna härleda användare geografiskt kan vara av nytta men det beror på din hemsidas innehåll.

Roller

Som du nu sett så har jag även lagt till ett fält som heter rollid. I detta fält tänkte jag att vi skulle göra ytterligare en tabell innehållande tänkbara roller som en användare kan tilldelas.

I denna tabell behöver vi inte använda så många olika roller. Viktigare är hur vi hanterar denna tabell. Jag tänkte nämligen att vi skall använda oss av bitwise-operationen här. Först funderar vi på vilka roller vi skall kunna tänka oss behöva.

Ej aktiv användare
Normal användare
Administrator
Superanvändare

En normal användare är egentligen alla. Om man är administrator så tillåts man göra lite mer och slutligen superanvändare som givetvis får göra allt. Vi tilldelar dessa roller ett rollid och här är det viktigt att du inte använder datatypen auto increment, vi skall nämligen ange värdet själva. De värden du kan använda är bl.a.: 0,1,2,4,8,16,32,64,128,256 osv. Så följande tilldelas:

Ej aktiv användare = 0
Normal användare = 1
Administratör = 64
Superanvändare = 128

En roll vi inte talat om är 0 (ej aktiv användare). Då det finns väldigt många medlemmar på pellesoft måste du även hålla reda på exempelvis om användarens e-post adress fungerar eller inte.

Vid nyhetsutskicken så går det ut flera tusen mail och av dessa kommer alltid några åter. För att undvika att skicka ut mail till dom vid nästa tillfälle kan du därför flagga upp dessa så du undviker det misstaget nästa gång du gör ditt utskick. Givetvis kan du välja att stänga av flaggan för nyhetsbrev eller helt enkelt ta bort användaren. Jag har dock valt denna metod just för att användaren kan ha bytt jobb och mailadress, eller att dess e-postserver tillfälligt är ur funktion. Återigen, valet är ditt hur du enklast löser detta.

Några ord om bitwise

Som du såg så skrev jag att du kunde använda 0,1,2,4,8,16,32,64,128,256 osv. Vi tar en riktigt snabb genomgång i bitwise operationer så du känner dig säker på detta. Låt säga att vi istället skall sätta olika status på en fil du har på din disk.

0 = normal
1 = directory
2 = read-only
4 = hidden
8 = system
16 = archive

Då kommer frågan, hur skall du med ett värde kunna ange om filen är read-only, hidden och system? Genom att slå ihop dess värden kommer vi att kunna få ett resultat:

(2 = read-only) + (4=hidden) + (8=system) = 14
Arkivflagga = 14

Om ni nu lagrar ner 14 I vår tabell så kan det tänkas omöjligt att veta om denna filen exempelvis är hidden, men så är inte fallet. Med ASP och VB’s funktion AND kan vi enkelt kontrollera detta med en matematisk fråga. Så här kan det se ut:


If Arkivflagga AND 4 Then
   ‘ Filen är Hidden
End If

På samma sätt kan du kontrollera om filen är både read-only och system:


If (Arkivflagga And 2) And (Arkivflagga And 8) Then
   ‘ Filen är både read-only och system
End If

Alltså, genom att använda samma princip kan vi kontrollera om den surfande besökaren tillhör en grupp som tillåts göra en eller annan sak. Så kommer vi också göra genom att automatiskt sätta varje ny medlem med rollen = 1, alltså normal användare.

Nu har vi kommit så långt att vi skapat oss två tabeller. Dels en tabell för användaren och ytterligare en tabell för den roll som varje specifik användare kan vara.

Ovan har jag även satt en relation mellan de två tabellernas RollId så de hålls samman.

Lägga till en egen datatyp

Nu ska vi ta och trixa till det lite. I SQL Server så finns massor av datatyper, varchar, integer, ntext, bit och många fler. Många gånger kan det även behövas ett Ja/Nej fält som kan användas. Detta tänkte jag att vi nu skulle ägna oss en minut åt. Jag kommer presentera ett script som min kollega Sven Engvall på Ontrax gjorde till en databas och jag sedan använt flitigt.

Datatypen blir Ja/Nej och kommer innehålla tecknet J eller N. Om inget anges när posten adderas så kommer det stå N default. Ta din Query Analyzer och kör följande script i en sekvens.

CREATE RULE JaNej_R AS @var in('J','N') OR @var IS NULL
GO
EXEC sp_addtype N'JaNej', N'char (1)', N'not null'
GO
EXEC sp_bindrule N'[dbo].[JaNej_R]', N'[JaNej]'
GO

Nu har du således skapat en datatyp som heter Ja/Nej och detta ser vi nu till att använda på två av de fälten vi precis skapade i användartabellen. Då ser det ut som följer:

Summering

Nu har vi pratat om vad vi bör ha med för fält i vår tabell, även finesser som vilken roll användaren tillhör. En liten bitwise-kurs gavs och slutligen en egen datatyp som är kraftfullt att använda. Det vi i nästa sektion kommer att beröra är tillbyggnaden av sidan som användaren skall få registrera sig på.

Upp