webForumDet fria alternativet

Inloggning utan sessioner

ASPur ASP

9 svar · 542 visningar · startad av Koggen

Medlem sedan juni 2002169 inlägg
Frågan#1

Hej

Jag söker tankar och tips på hur man skapar en inloggning till administration utan att använda sessioner. Tanken är att man skall behålla sin behörighet så länge man finns på administrationssidorna. Behörighetskontrollen görs mot en databas.

Man skall inte komma åt administrationssidorna genom att skriva in URL:en.

Lite tankar och idéer vore ytterst välkomna.

Tack

Medlem sedan jan. 2004128 inlägg
#2

Kanske kontrollera IP och lagra det som senast inloggat i databasen? Är IP't samma som det som finns där så får man härja, annars visas loginformuläret?

Medlem sedan dec. 19996 522 inlägg
#3

Du kan väll köra NT-inloggning, om du har tillgång till burken. Iof kör de en sorts sessions men inte sessions av vanlig asp-typ.

Medlem sedan feb. 20013 023 inlägg
#4

SprayMaphia skrev:

Kanske kontrollera IP och lagra det som senast inloggat i databasen? Är IP't samma som det som finns där så får man härja, annars visas loginformuläret?

Det är inte så lyckat då flera personer kan sitta på ett IP-nummer sett ur webbserverns synvinkel.

Medlem sedan apr. 20031 660 inlägg
#5

HEJ!

SprayMaphia skrev:

Kanske kontrollera IP och lagra det som senast inloggat i databasen? Är IP't samma som det som finns där så får man härja, annars visas loginformuläret?

Skulle jag inte rekommendera alls!

1. Man har inte alltid samma ip
2. Har man samma ip, har andra på tex ett företaget det också
3. Är det ett intranet och man använder DHCP, får man inte alltid samma ip
4. Är det ett intranet med fasta ip, kan någon annan använda din dator

Jag skulle råda till NT-inloggning, eller cookies.
Varför vill du inte ha sessioner?

Medlem sedan feb. 200112 078 inlägg
#6

Om du skall ha sådan data i cookies, så föreslår jag att du krypterar/hashar dem först.

Vidare så ställer jag samma fråga som J.N.; varför vill/kan du inte ha sessioner?

Medlem sedan juni 2002169 inlägg
#7

Tack för alla svaren!

I tur och ordning:
IP-kontroll - bra idé! Jag använder en IP-koll redan för att visa en del interna länkar på startsidan. Alla användare med behörighet har statisk IP, så det borde funka bra. Nackdelen är ju att dom då bara kan logga in från sin egen burk.

Jag har inte kontroll över servern, så den s.k. NT-inloggningen är inte aplicerbar här. Jag finns inte ens på samma ort som servern.

Den sessionslösa inloggningen är bara en temporär lösning. Serveradmin har nämligen stora problem eftersom sessionerna dör oförklarligt efter olika lång tid. Detta hände efter en ominstallation från Win2k till Win2003.

Sedan några veckor ligger administrationssidorna nere eftersom inga sessioner varar mer än max ett par minuter. Jag har postat frågor i webbserver-forumet, men ingen har kunnat hjälpa mig med det fenomenet.

Har någon en idé om själva grundproblemet - varför dödar Win2003 sessionerna som fungerade perfekt i win2k ..?

Tack

Medlem sedan juni 20034 013 inlägg
#8

Du får använda cookies. Jag har tidigare (på eforum) skrivit ihop lite grann om hur det funkar. Jag har dock använt Php som exempel, men det är ju samma princip:

"Nej, jag känner inte till något ställe där det förklaras bra, så jag sätter väl mig ner och skriver en stump. Klipp ur och spara :-)

Det här med inloggning består av tre steg, skulle man kunna säga. Först ska användaren mata in namn och lösenord (1), sedan ska datorn kolla om det stämmer (2) och slutligen ska den berätta för övriga sidor på webbplatsen att personen gjort en korrekt inloggning (3), så man inte måste mata in uppgifterna på nytt på varje sida, för det skulle man ju snabbt tröttna på.

För steg ett gör vi ett litet forumlär i html:

(login.html)

<form action="verify.php" method="post" name="login">
Användarnamn: <input type="text" name="username"><br>
Lösenord: <input type="password" name="password"><br>
<input type="submit" name="done" value="Logga in">
</form>

Sedan är det dags för steg två, nämligen att kolla om uppgifterna stämmer:

(verify.php)

<?php
if ($_POST["username"] == "rätt_användarnamn" && $_POST["password"] == "rätt_lösenord")
{
// Godkänt.
}
else
{
// Ej godkänt.
}
?>

Om du vill ha flera olika användarnamn och lösenord som man ska kunna logga in med kan du lägga dessa i en associativ array, så här:

$passwords["användarnamn"] = "lösenord";

Exempelvis:

$passwords["alice"] = "gurka";
$passwords["bob"] = "tomat";

If-satsen ovan för att kolla inloggningsuppgifterna blir då så här:

if ($passwords[$_POST["username"]] == $_POST["password"])

* * *

Nu kommer vi till steg tre, och då blir det lite värre, för vi kan ju inte bara använda en variabel för att tala om att personen är inloggad, för användaren kan nämligen själv välja vilka variabler som ska skickas mellan sidor och vad de ska innehålla. Det har man ingen kontroll över som webbplatsinnehavare.

Om du bara gjorde så att efter att Alice hade loggat in sparade värdet "Alice är inloggad" i en cookie (som det heter) så skulle hon kunna ändra det till "Bob är inloggad" utan att du märkte något och vips skulle hon komma åt Bobs saker (om du nu har någon uppdelning). Men vad värre är, om Mallory kommer och vill logga in så skulle hon kunna skicka "Alice är inloggad" till din webbplats och bli inloggad utan att ange något lösenord.

Därför måste vi använda oss av lite kryptering, närmare bestämt en hash-funktion som är inbyggd i php och heter md5.

MD5 är som en svart låda. Du stoppar in något i den och så får du något annat tillbaka, men du vet inte hur det gick till. (Fast om du skulle vilja veta så finns faktiskt formeln beskriven här: http://www.faqs.org/rfcs/rfc1321.html )

När man skickar något till md5 så får man alltid 32 tecken tillbaka oavsett hur många tecken man skickade. Och dessa 32 tecken ska inte på något vis påminna om det du skickar in, för det ska inte gå att gå bakvägen och få reda på vad man skickade in, utan md5 funkar bara åt ett håll. Men du får alltid samma resultat med md5 om du skickar in samma sak, och det är det som är finessen; det är så man kan kontrollera att det stämmer.

När nu Alice loggar in så sätter du återigen värdet "Alice är inloggad", men du kör också "Alice är inloggad" genom md5 och får: 605d4982c9b4849ad73522f7ddc75b98 och sparar även det värdet i en cookie.

När Alice sedan försöker gå in på någon sida skickar hennes dator över cookien "Alice är inloggad" och 605d4982c9b4849ad73522f7ddc75b98 och du kör md5 på "Alice är inloggad" och jämför med de 32 tecken hon skickade med. Stämmer det så vet du att hon inte har ändrat på inloggningen. För om hon nu skulle ändra till "Bob är inloggad" så skulle det bli dc011293eefc34a6c91727f09daa2184 när du kör md5 på det, och då stämmer det inte med de 32 tecken hon fick av dig tidigare.

Fast nu råkar ju Alice vara lite intelligent. Hon har nämligen också tillgång till php och därmed md5-funktionen. Så, hon tar helt enkelt och kör "Bob är inloggad" genom md5 och kan därmed skicka de rätta 32 tecknen till dig så du tror att det verkligen är Bob som är inloggad.

Ja, där har vi ännu ett problem vi måste lösa, och det går att lösa med hjälp av en hemlig kod. Vi antar för exemplets skull att den hemliga koden är "hemlig_kod". Innan vi nu skickar "Alice är inloggad" till md5 så sätter vi ihop det med "hemlig_kod" så vi får: "Alice är inloggadhemlig_kod". När vi skickar det genom md5 får vi: 71d2e5028c2b48d68c33332e51788d10 och dessa 32 tecken skickar vi till Alice tillsammans med "Alice är inloggad", men den hemliga koden får hon absolut inte.

Nu kan inte Alice ändra "Alice är inloggad", för trots att hon har tillgång till md5 så kan hon inte räkna ut de 32 tecknena, för till det behövs den hemliga koden.

Men det finns fortfarande ett problem. Mallory hälsar nämligen på hos Alice en dag och hittar de 32 tecknena från din sida som står för "Alice är inloggad". Med hjälp av dessa kan hon nu logga in som Alice från sin egen dator.

För att lösa det problemet får man tillsammans med den hemliga koden också baka in ett klockslag, så att de 32 tecknen bara gäller exempelvis en timme, sedan måste man logga in på nytt. Då har Mallory ingen nytta av koden eftersom den ändå är värdelös innan hon hunnit komma hem.

Men, i princip så här (vid godkänd inloggning):

$hemligKod = "hemlig";
$tid = time() + 3600;
$hash = md5($_POST["username"] . $tid . $hemligKod);
SetCookie("username", $_POST["username"], time() + 3600, "/", "", 0);
SetCookie("tid", $tid, time() + 3600, "/", "", 0);
SetCookie("hash", $hash, time() + 3600, "/", "", 0);

Sedan, på varje sida som kräver inloggning för att ses gör du så här:

$hemligKod = "hemlig";
if (($tid < time()) || md5($username . $tid . $hemligKod) != $hash)
{
header("Location: login.html");
exit;
// Ej godkänd inloggning.
}
// Här kommer den riktiga sidan.

De här sakerna som jag berättar för dig nu är som du förstår väldigt viktiga när man jobbar med inloggning, men tyvärr känner inte alla som jobbar med sånt till dem. (Exempelvis har Hotmail missat på en del punkter vilket gör att man kan komma åt andras konton.) Så det är därför jag talar om ganska mycket, så att du förhoppningsvis åtminstone ska komma ihåg att det är väldigt mycket man måste tänka på för att få det säkert."

Medlem sedan juni 2002169 inlägg
#9

Tack för det utförliga svaret.... i PHP huh... ;-)

Jag har dock en känsla av att cookies kommer att gå samma väg som min tidigare lösning med sessioner, eftersom ju sessioner är en typ av cookies fast på servern då. Men om jag inte hittar någon lösning på sessionsproblemet kan cookies vara värt att titta på.

Men vi kan väl inte vara dom enda med sessionsproblem på Win2003!? Man hittar många såna frågor på massor av olika forum, men inte många svar tyvärr.

Medlem sedan juni 20034 013 inlägg
#10

Sessioner hanteras av servern, cookies av klienten. Det är servern du har något problem med, så det finns ingen anledning till att cookies skulle krångla.

En session funkar så här:
* Användaren besöker sidan utan att ha någon cookie.
* Servern skapar en ny fil för användarens sessionsdata.
* Filnamnet (sessions-id:t) skickas i en cookie till användaren.
* Eventuella sessionsvariabler sparas i filen.
* När användaren återvänder så har han/hon en cookie med ett sessionsnummer i. Servern kollar om det finns någon fil med det namnet. Finns det så är sessionen giltig (och filen innehåller dess variabler), annars inte.

Ditt problem verkar alltså vara att sessionsfilerna av någon anledning tas bort från servern.

För att en cookie ska tas bort så måste antingen datumet som du sätter den på i din asp-kod ha gått ut, eller så måste användaren radera den.

143 ms totalt · 3 externa anrop · v20260731065814-full.25f56b17
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
140 ms — hämta tråd, inlägg och bilagor (db)