/ Forside / Teknologi / Udvikling / Java Scripts / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Java Scripts
#NavnPoint
molokyle 5410
Klaudi 2799
smorch 2439
kim 1360
Harlekin 1134
bentjuul 984
gibson 800
severino 695
Random 675
10  konsulent.. 626
Identificer maskine bag nat
Fra : Leif Neland


Dato : 08-01-09 11:38

For at forhindre brugere i at dele passwords, så vil jeg sørge for at
hvert login kan bruges fra een maskine af gangen.

Men da der sider en håndfuld maskiner bag nat, så duer
$_SERVER["REMOTE_ADDR"] ikke.

En cookie duer umiddelbart heller ikke, da det skal være "lovligt" at
bruge flere browsere på een gang, og svjv gemmer IE og Firefox ikke
cookies samme sted.

Jeg har prøvet en java-applet, der kan læse lokal-ip'en og lægge den i
en hidden / cookie, men den er ikke så stabil, på nogle maskiner er der
tilsyneladende ikke java, eller appletten bliver blokeret. En enkelt
maskine giver ip'en 127.0.0.1

Er der andre måder at skelne de enkelte maskiner fra hinanden?

Bortset fra et sige til brugerne: Lad vær...

Leif

 
 
Stig Johansen (08-01-2009)
Kommentar
Fra : Stig Johansen


Dato : 08-01-09 14:40

Leif Neland wrote:

> Er der andre måder at skelne de enkelte maskiner fra hinanden?

Ja, men lidt afhængig af hvad du har til rådighed på server siden.

I stedet for cookies, kan du indføre et 'token', som bliver båret med.

Eksempelvis:
http://my.site.somewhere/ page>/<token>/showme.something

men det er nok ikke en 'clientside' løsning, som du måske er ude efter.

--
Med venlig hilsen
Stig Johansen

Leif Neland (08-01-2009)
Kommentar
Fra : Leif Neland


Dato : 08-01-09 18:57

Stig Johansen skrev:
> Leif Neland wrote:
>
>> Er der andre måder at skelne de enkelte maskiner fra hinanden?
>
> Ja, men lidt afhængig af hvad du har til rådighed på server siden.
>
> I stedet for cookies, kan du indføre et 'token', som bliver båret med.
>
> Eksempelvis:
> http://my.site.somewhere/ page>/<token>/showme.something
>
> men det er nok ikke en 'clientside' løsning, som du måske er ude efter.
>

Det har den samme ulempe som cookies, at der ikke fra serveren kan
skelnes mellem om den samme bruger bruger flere (forskellige) browsere
fra den samme maskine, hvilket man godt må, og fra forskellige maskiner,
hvilket man ikke må.

Leif

Rune Jensen (09-01-2009)
Kommentar
Fra : Rune Jensen


Dato : 09-01-09 02:10

Leif Neland skrev:
> Stig Johansen skrev:

>> I stedet for cookies, kan du indføre et 'token', som bliver båret med.
>>
>> Eksempelvis:
>> http://my.site.somewhere/ page>/<token>/showme.something
>>
>> men det er nok ikke en 'clientside' løsning, som du måske er ude efter.

Det tror jeg så heller ikke.

> Det har den samme ulempe som cookies, at der ikke fra serveren kan
> skelnes mellem om den samme bruger bruger flere (forskellige) browsere
> fra den samme maskine, hvilket man godt må, og fra forskellige maskiner,
> hvilket man ikke må.

Eneste, jeg kan foreslå, er heller ikke 100% pålideligt, men...
Når bruger opretter sig første gang, så lav en ID i en cookie, hvor du
bruger tiden fra [årstal] til logon i sekunder.

Dette gemmer du i en database samtidig.

Når brugeren vil logge på igen, ledes efter cookien, som skal være
identisk med den i databasen, og en ny tidskode laves.

Vil en nummer to bruger logge på fra en anden maskine, kan han ikke, da
han vil få en højere tidskode end den i databasen.

Du laver cookien som lokal cookie. I ASP kan det gøres sådan:
Response.Cookies(cookieName).Path

Ovenstående har et stort men. Hvis oprindelig bruger sletter sin cookie,
står man i et dilemma. Man kan ikke finde cookie, og kan derfor ikke
logge ind. Heller ikke, selv om brugeren er lovlig.

I så fald, kan man sende brugeren en ny kode til dennes email (via
f.eks. "Har du problemer med at logge ind?"). Noget juks, men som sagt
allerførst, det er ikke 100%. Jeg tror iøvrigt heller ikke, der findes
en sådan metode, som er 100%....

Ovenstående identificerer jo ikke én enkelt maskine unikt på en bestemt
IP, men den maskine, som cookien ligger på fra start, og sørger for, der
ikke kan køre to sessioner med samme password samtidigt (to ens cookies).

Desuden vil du aldrig kunne gardere dig imod, at en helt anden bruger
kommer til oprindelig bruger, og benytter dennes konto/profil fra hendes
maskine.

Når tales unik identifikation af maskiner, så benytter flere sig af
maskinens opbygning, specielt hardware, som en del af et elektronisk
fingeraftryk. At lave et sådant, som også er bare nogenlunde pålideligt,
vil formentlig kræve, man installerer et program af en art (f.eks. BHO),
som samler disse oplysninger, ligesom de selvfølgelig skal registreres i
en database hos serviceudbyderen. Og der skal (some how) registtreres
hver gang, der foretages udskiftninger i hardwaren. Det tror jeg mange
brugere vil værgre sig imod. Med mindre, du virkelig kan tilbyde noget godt.


MVH
Rune Jensen

Rune Jensen (09-01-2009)
Kommentar
Fra : Rune Jensen


Dato : 09-01-09 03:31

Rune Jensen skrev:

> Ovenstående identificerer jo ikke én enkelt maskine unikt på en bestemt
> IP, men den maskine, som cookien ligger på fra start, og sørger for, der
> ikke kan køre to sessioner med samme password samtidigt (to ens cookies).

OK, glemte lige en ting. Du kan logge sessionen med et - forholdsvist -
sikkert ID. Et "fingeraftryk" baseret på oplysninger i HTTP-HEADeren.

Når brugeren logger på, kan du lave fingeraftrykket som en
sammenblanding af IP, user_agent, accept, connection osv.

Det vil ikke sikre, man ikke kan køre fra andre maskiner, men det vil
være en nem måde at minimere chancen for flere sessioner samtidigt.

Evt. kan du sammenholde det med en tidskode i en cookie, som så i stedet
oprettes ved hvert log in.

Det vil så f.eks. betyde, at hvis man sidder på en IE og logger ind, vil
man ikke samtidigt kunne side på en FF og logge ind.

Du skal så have en automatisk sessionsudløb, ellers er brugeren bundet
til en bestemt maskine, indtil der logges ud.

Eksempel:

1. bruger 1 vil logge ind.

1.a. Der kigges i DB, hvad status for brugeren er.
1.b. Er han logget ind, kigges på, om cookien svarer til tidskoden i DB,
samt om HTTP-ID svarer til DB og ny tidskode og HTTP-ID oprettes. Er der
ingen cookie, kan han ikke logge ind.

1.c Er han logget ud, logges ind, og ny tidskode og HTTP-ID oprettes

AD1 kan sammenfattes som at man i en database lister hvert brugernavns
status loggedin/loggedoff. Hvis man forsøger at logge ind fra ny
browser, logges ud af anden session på anden browser, såfremt det er den
rigtige bruger.

2. Brugeren vil browse gennem siderne.
2.a. der kigges på, om HTTP-IDet svarer til DB, om cookie eksisterer og
om login-tidskode svarer til DB
2.b. gør det ikke det, får han en fejlside

AD2 kan sammenfattes som, at man kopierer linket fra en allerede
in-logget bruger til en anden maskine, og at dette ikke er muligt (med
mindre der køres med samme opsætning/browser og han hugger cookien også,
samt kører fra samme IP)

Brugernavnet, tidskode skal så ligge i cookien. HTTP-ID kan laves
dynamisk, da disse data sendes med HEADeren.

3. Brugeren vil logge ud
3.a. Der kigges på, om cookie eksisterer, og om tidskode svarer til DB,
samt om HTTP-ID svarer til DB. Gør den ikke det, kan han ikke logge ud.
3.b. Hvis den gør, ændres status til logged off, og cookie slettes.

NOTE: Hvis en bruger er logget ind, og i denne session f.eks. opdaterer
sin browser, vil han ikke videre blive godtaget som logget ind, fordi
user_agent ændrer sig. Samme, hvis han ændrer sprog. F.eks.

Ved ikke, om det giver mening. Det er sent (eller tidligt, alt efter
hvor man ser det fra), og det ser lidt komplekst ud...


MVH
Rune Jensen

Erik Ginnerskov (09-01-2009)
Kommentar
Fra : Erik Ginnerskov


Dato : 09-01-09 23:12

Rune Jensen wrote:

> Når bruger opretter sig første gang, så lav en ID i en cookie, hvor du
> bruger tiden fra [årstal] til logon i sekunder.
>
> [en længere teknisk udredning]

Jeg tror at løsningen er noge serverside, hvor brugers login tjekkes i en
tabel og hvor der så i en anden tabel med udløb ved logout/sessiononend
laves en record indeholdende brugers ID fra tabel et plus den benyttede
maskines MAC-adresse (en kode, der læses fra netkortet).

Det medfører at:

Er brugers ID ikke i tabel to, kan han logge ind fra hvorsomhelst.

Er bruger logget ind, kan han fra samme maskine komme ind med
andre browsere samtidig, men hans login kan ikke bruges fra
andre maskiner uanset IP, da en anden maskine vil have en
anden MAC-adresse.

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


Stig Johansen (10-01-2009)
Kommentar
Fra : Stig Johansen


Dato : 10-01-09 00:31

Erik Ginnerskov wrote:

> plus den benyttede
> maskines MAC-adresse (en kode, der læses fra netkortet).

Problemet er, at man ikke kan få fat i oplysninger til at identificere en
maskine via Javascrpit.

Det vil også være et sikkerhedsproblem.

Leif har fået 2 løsningsforslag, som vil virke 'forretningsmæssigt', men
ikke 'automagisk'.

--
Med venlig hilsen
Stig Johansen

Stig Johansen (09-01-2009)
Kommentar
Fra : Stig Johansen


Dato : 09-01-09 04:29

Leif Neland wrote:

> Det har den samme ulempe som cookies, at der ikke fra serveren kan
> skelnes mellem om den samme bruger bruger flere (forskellige) browsere
> fra den samme maskine, hvilket man godt må, og fra forskellige maskiner,
> hvilket man ikke må.

Den er måske lidt langt ude, og muligvis ikke realisérbar men man kunne
identificere de enkelte maskiner via en slags 'metatag' i useragent i hver
enkelt browser på hver maskine.

Det vil sikkert kræve en del vedligeholdelse.

--
Med venlig hilsen
Stig Johansen

Leif Neland (13-01-2009)
Kommentar
Fra : Leif Neland


Dato : 13-01-09 09:47

Leif Neland skrev:
> For at forhindre brugere i at dele passwords, så vil jeg sørge for at
> hvert login kan bruges fra een maskine af gangen.
>
> Men da der sider en håndfuld maskiner bag nat, så duer
> $_SERVER["REMOTE_ADDR"] ikke.

Der er kun 2 steder, der er nat, hvor dette er et problem.
Der kan jeg sætte en lokal "myip.dk"-agtig service op.

Så jeg kan serverside sætte javascript ind i login-siden, hvis requestet
kommer fra en af de nat'tede steder.

Men må en side køre javascript, der henter data fra et andet sted end
det er loadet fra, indsætte det i f.ex. et hidden felt, og sende det til
det første sted?

Altså en side fra www.domain.dk kører javascript, der henter et svar fra
server.localnet/myip.php og det svar bliver så submittet ved login til
www.domain.dk

Eller vil browseren nægte at gøre det af sikkerhedsgrunde?

Leif

Stig Johansen (13-01-2009)
Kommentar
Fra : Stig Johansen


Dato : 13-01-09 14:08

Leif Neland wrote:

> Men må en side køre javascript, der henter data fra et andet sted end
> det er loadet fra, indsætte det i f.ex. et hidden felt, og sende det til
> det første sted?

Ja, det er sådan alle de der reklamer op popup's virker.

> Eller vil browseren nægte at gøre det af sikkerhedsgrunde?

XMLHTTPRequest vil nok ikke virke på tværs af domæner (forhåbentlig).

--
Med venlig hilsen
Stig Johansen

Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408849
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste