Gå til innhold

Anbefalte innlegg

Før i tiden kunne man logge på endel sider ved å ha brukernavn og passord i linken, slik som f.eks. http://brukernavn:[email protected]/passor...et/mystisk.html

Nå hører jeg at det, med siste oppdatering i Internet Explorer, ikke går ann å gjøre det slik lengre. Så har man kunder som ikke ønsker å skrive brukernavn og passord for å komme inn på sin egen passordbeskytta side. De ønsker fortsatt å bruke Internet Explorer med siste oppdateringer, og de ønsker fortsatt passordsikra sider.

 

Noen "nye" måter å linke på? Noe software som kan installeres på server? Cookies? Noe annet? Noen løsninger?

Jeg er åpen for forslag.

Lenke til kommentar
Videoannonse
Annonse

Sorry at det tok så lang tid å svare, hadde noen gentoo problemer i går, og glemte dette helt.

 

Det som kanskje går an er å mekke en php "autentiserings-portal" ting.

blabla.com/auth.php?name=bla&pw=bla&hash=bla eller noe slikt.

 

Nå vet jeg ikke om php kan "legge inn" basic auth info i klienten, men det kan være verdt et forsøk. Evt. mekke systemet om til å bruke php-basert verifisering (php session id ting).

Lenke til kommentar

I prinsippet er det vel bare noe slikt:

 

Litt psuedo-kode (type pythonesque, generell)

Klient-siden:

user=logged_on_user
secret="Eer4bexi"
date=day+month+year
ip=user_ip
hash=md5(user+date+ip+secret)

url="http://www.blabla.com/auth.php"

print url+'?name='+user+'&hash='+hash

 

Server side

user=get_user
hash=get_hash
secret="Eer4bexi"
date=day+month+year
ip=user_ip

if user isin database:
 if hash = md5(user+date+ip+secret):
    do_verification

 

secret må være samme på server og klient, og bør være 5-15 bostaver og tall.

hva som legges inn i hash'en er opp til hver enkelt, bare husk at stringen som skal hashes må kunne genereres på begge maskinene.

 

Fordeler:

  • klientsiden tar all verifiseringen, passord trenger ikke lagres i det hele tatt på server side
  • Linken vil bare være gyldig en dag.
  • Kan bare brukes ifra den maskinen som fikk linken.
  • Passordet vil være umulig å finne ut av fra linken.

Ulemper:

  • Hvis man finner ut secret kan man late som man er hvem man vil. Dette kan motvirkes ved å legge til passord og, men det kan by på andre problemer (som f.eks hvis passord ikke blir lagret i klartekst på server)

 

Hvordan er nettverket bygd opp? Er det domene-system? Hvor i systemet står serverene? (på internett?) Vanskelig å gi klare ideer når jeg ikke vet hvordan systemet er.

Lenke til kommentar

Det er, såvidt jeg forstår, brukermaskiner i et nettverk i en bedrift. De logger seg på, via Internet Explorer, en intranettside på husets interne server. Herfra har de linker, derav enkelte av sidene er passordbeskyttet... Forskjellige rettigheter til forskjellige brukere er ikke viktig på denne siden. Her går alle over en kam. (Det kan tenkes at de har forskjellige passord for å logge på, men til den spesielle sida er det bare et brukernavn og passord som gjelds.)

Lenke til kommentar

Hmm.. Skjønner. Ser ut som at user:pass@host type system er beste løsningen ja. Noe annet vil kreve mye arbeid.

 

Har tenkt litt. Hvis microsoft sperrer for det, kan det godt hende at det finnes en registry option for å slå det på igjen. Det kan også hende at javascript har en funksjon for nettopp det der, som ikke krever user@host type url.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...