mboost-dp1
Omkring OpenID
Jeg sidder og fifler med noget brugersystems kode til web, og så tænkte jeg på OpenId.
Og det er jo meget fint at man kan logge ind på newz.dk med openid, men hvad er det entlige formål når man stadigvæk skal bruge et password til at oprette en bruger med?
Hvis jeg allerede har et password og brugernavn til siden, hvorfor skal jeg så benytte openid ?
Og det er jo meget fint at man kan logge ind på newz.dk med openid, men hvad er det entlige formål når man stadigvæk skal bruge et password til at oprette en bruger med?
Hvis jeg allerede har et password og brugernavn til siden, hvorfor skal jeg så benytte openid ?
Fordi du slipper for at huske det password ekstra.
Desuden kan man også sagtens undgå det, men så bliver man jo nødt til at *kræve* at folk har et openID for at kunne bruge siden.
Desuden kan man også sagtens undgå det, men så bliver man jo nødt til at *kræve* at folk har et openID for at kunne bruge siden.
Det er fordi du ikke tænker NOK over det.
Hvis man bruger samme password alle steder, og ønsker at skifte det, så er det noget lort. Med OpenID kan man gøre det ET sted, og så er man færdig.
Ud over det, så kan man authenticate på et uendeligt antal måder med OpenID -- der er ingen der siger man SKAL bruge et password. OpenID gør det muligt at bruge langt mere sikre former for authentication, end traditionelt user/password.
Ydermere er OpenID decentraliseret, så man kan skifte fra en udbyder til en anden hvis man er utilfreds.
Der er mange fordele, men hvis du allerede har besluttet dig for at OpenID sucks, så er der altså ingen grund til at du spørger og at vi bruger tid på at forklare fordelene ved OpenID. :-)
Hvis man bruger samme password alle steder, og ønsker at skifte det, så er det noget lort. Med OpenID kan man gøre det ET sted, og så er man færdig.
Ud over det, så kan man authenticate på et uendeligt antal måder med OpenID -- der er ingen der siger man SKAL bruge et password. OpenID gør det muligt at bruge langt mere sikre former for authentication, end traditionelt user/password.
Ydermere er OpenID decentraliseret, så man kan skifte fra en udbyder til en anden hvis man er utilfreds.
Der er mange fordele, men hvis du allerede har besluttet dig for at OpenID sucks, så er der altså ingen grund til at du spørger og at vi bruger tid på at forklare fordelene ved OpenID. :-)
Ja, men pointen frafalder stadig hvis man ikke kan oprette en bruger uden at benytte et password.
Men alle implementationer af openid login jeg har set kræver at man allerede har en bruger. Hvilket jeg undre mig over.
Men alle implementationer af openid login jeg har set kræver at man allerede har en bruger. Hvilket jeg undre mig over.
Der er mange fordele, men hvis du allerede har besluttet dig for at OpenID sucks, så er der altså ingen grund til at du spørger og at vi bruger tid på at forklare fordelene ved OpenID. :-)*suk* Det er ligesom alle andre fanatikerne, der må aldrig være noget dårligt ved et produkt de benytter, og man må slet ikke diskutterer det.
#5: http://stackoverflow.com/ kræver ikke at man opretter bruger først.
Og beklager hvis jeg lyder fanatisk, men du lyder som en ignorant, og det er mindst lige så slemt :P
Og beklager hvis jeg lyder fanatisk, men du lyder som en ignorant, og det er mindst lige så slemt :P
OpenID er genialt, men folk er generelt for konservative eller "web 2.0"-forskrækkede til at tage det til sig som de burde.
Der er masser af fordele over at bruge samme password på alle sites, som du foreslår. For det første behøver du slet ikke bruge et password til at identificere dig via OpenID - jeg bruger f.eks. et X.509 certifikat overfor min OpenID udbyder, hvilket betyder at mine brugerkonti på OpenID-sites rundt omkring er langt mere sikker end mine brugerkonti på sites der ikke understøtter OpenID, fordi et certifikat er umuligt at gætte.
For det andet er min OpenID-udbyder sat op som 'single sign on' hvilket betyder at jeg kan nøjes med at logge ind én gang hver gang jeg åbner browseren - derefter er jeg logget ind på alle andre sites der understøtter OpenID til jeg lukker browseren igen.
For det tredje skal man normalt ikke oprette en bruger før man kan logge ind med OpenID. At man skal det alligevel på nogle sites skyldes historiske forhold. Man skal ideelt set bare kunne indtaste sin ID, klikke 'login', autentisere sig overfor udbyderen, og så være inde.
Der er masser af fordele over at bruge samme password på alle sites, som du foreslår. For det første behøver du slet ikke bruge et password til at identificere dig via OpenID - jeg bruger f.eks. et X.509 certifikat overfor min OpenID udbyder, hvilket betyder at mine brugerkonti på OpenID-sites rundt omkring er langt mere sikker end mine brugerkonti på sites der ikke understøtter OpenID, fordi et certifikat er umuligt at gætte.
For det andet er min OpenID-udbyder sat op som 'single sign on' hvilket betyder at jeg kan nøjes med at logge ind én gang hver gang jeg åbner browseren - derefter er jeg logget ind på alle andre sites der understøtter OpenID til jeg lukker browseren igen.
For det tredje skal man normalt ikke oprette en bruger før man kan logge ind med OpenID. At man skal det alligevel på nogle sites skyldes historiske forhold. Man skal ideelt set bare kunne indtaste sin ID, klikke 'login', autentisere sig overfor udbyderen, og så være inde.
Hmm, dog fejler konceptet lidt, hvis et predefineret brugernavn allerede er taget.
Sidder og leger med specifikationerne nu. Og jeg bryder mig ikke om deres dokumentation.
Opbygningen virker faktisk meget underligt, og alt for komplext set i forhold til hvad det burde være.
Samt det at man skal forholde sig til at man ikke nødvendigvis kan hente det date man har requested. Alt alt for løs en specifikation.
Begynder at forstå at Microsoft og Google ville lave deres egne :p
Sidder og leger med specifikationerne nu. Og jeg bryder mig ikke om deres dokumentation.
Opbygningen virker faktisk meget underligt, og alt for komplext set i forhold til hvad det burde være.
Samt det at man skal forholde sig til at man ikke nødvendigvis kan hente det date man har requested. Alt alt for løs en specifikation.
Begynder at forstå at Microsoft og Google ville lave deres egne :p
Kan slet ikke se hvad problemet er. Overvej evt. at bruge standard implementationerne af OpenID i stedet for at begynde at genopfinde hjulet. Godt nytår.
Problemet er hele måden der forventes man foretager requests på. At man skal sende et post request, for at få et post request tilbage på ens egen side.
Istedet for bare at requeste den data man skal bruge, og så aflæse den.
Det er en elendig måde at opbygge en protokol. Samt at implementere det rent kodemæssigt er et komplext mareridt.
Man kan benytte biblioteker, men desværre er de mest gængse biblioteker extremt bloatet.
Personligt vil jeg bare have:
bool OpenId.Auth(string IdentUrl)
object OpenId.SimpleRequestInfo(string[] params) (via. simpleRequest specifikationen).
Plus deres dokumentation for at udvikle APIs er elendig og ikke særlig forklarende. Samt at det hele bygger på simple plaintext POST requests, som er næsten umuligt at opbygge automatisk, hvoraf næsten alle nuværende APIs laver det som en string, manualt, uden brug af et bagliggende framework.
Jeg er dybt skuffet over at man ikke kan skrive et auth check på 5-10 linjers kode. Mere burde ikke være påkrævet.
Samt jeg er ekstra skuffet over at det er nødvendigt at crawle en HTML side for at finde den nødvendige url til Serveren der skal håntere de nødvendige requests.
Det er et ekstrem spild af resourcer.
Istedet for bare at requeste den data man skal bruge, og så aflæse den.
Det er en elendig måde at opbygge en protokol. Samt at implementere det rent kodemæssigt er et komplext mareridt.
Man kan benytte biblioteker, men desværre er de mest gængse biblioteker extremt bloatet.
Personligt vil jeg bare have:
bool OpenId.Auth(string IdentUrl)
object OpenId.SimpleRequestInfo(string[] params) (via. simpleRequest specifikationen).
Plus deres dokumentation for at udvikle APIs er elendig og ikke særlig forklarende. Samt at det hele bygger på simple plaintext POST requests, som er næsten umuligt at opbygge automatisk, hvoraf næsten alle nuværende APIs laver det som en string, manualt, uden brug af et bagliggende framework.
Jeg er dybt skuffet over at man ikke kan skrive et auth check på 5-10 linjers kode. Mere burde ikke være påkrævet.
Samt jeg er ekstra skuffet over at det er nødvendigt at crawle en HTML side for at finde den nødvendige url til Serveren der skal håntere de nødvendige requests.
Det er et ekstrem spild af resourcer.
Windcape (13) skrev:Samt at det hele bygger på simple plaintext POST requests, som er næsten umuligt at opbygge automatisk, hvoraf næsten alle nuværende APIs laver det som en string, manualt, uden brug af et bagliggende framework.
Jeg har ingen forstand på openid, men lige den der ved jeg noget om.
POST-requests er noget af det nemmeste at bygge op. Det er nok derfor nogle er fristet til at gøre det manuelt, det ville jeg måske også gøre, afhængigt af hvilke API'er jeg har til rådighed.
Windcape (13) skrev:Samt jeg er ekstra skuffet over at det er nødvendigt at crawle en HTML side for at finde den nødvendige url til Serveren der skal håntere de nødvendige requests.
Hvordan ville du ellers gøre det? Bemærk at det er et ønske til systemet, at man kan bruge en URL, som også bliver brugt til andre ting. Fx. sin hjemmeside.
Hvis du laver en begrænsing om at URL'en ikke indeholder andet end din openid, ryger en masse af openid's fordele.
Windcape (13) skrev:Det er et ekstrem spild af resourcer.
Æh...
Windcape (14) skrev:Hvorfor overhovedet forsøge når der ikke er 100% chance for at få det ønskede data?
Brokker du dig ikke bare for at holde dig vågen nu?
Finten er: Når man opretter en bruger vil hjemmesiden måske vide mere end bare dit openid. Måske er en email-adresse påkrævet.
Så synes nogle jo det er smart, hvis hjemmesiden kan finde ud af det automatisk, ud fra data i din openid. Andre bryder sig ikke om den feature. Måske vil de vide præcist hvad der bliver udleveret (uden at benytte en openid-service der håndterer det problem), måske ønsker de at visse informationer er forskellige fra hjemmeside til hjemmeside.
Hvis hjemmesiden mangler data, kan den bede brugeren om det, præcist som normalt. Får hjemmesiden al ønsket data, kan det trin springes over.
Det er da smart! ... Jo det er.
Ja, men det betyder at så skal en registration service først teste om data'en overhovedet er der, og så derefter renderer nødvendige input forms der tager sig af det manglende data.
Det er så her jeg synes at brugeren ligeså godt kunne udfylde informationerne igen.
Hvis OpenId havde sikkerhed for ALTID at udlevere email og brugernavn ville jeg kunne se det brugbare i det. Ellers ikke.
Til services som kræver valid email til registration (der er cirka alting i dag).
Jeg synes jo at windcape.openidservice.tld skulle være den reele service, og ikke noget tilfældigt.
I forbindelse med egen hjemmeside skulle det så være mydomain.dk/openid som var refference til selve servicen.
Det ER et spild af resourcer at skulle crawle et HTML dokument for først derefter foretage endnu et request (det medfører også unødvendig load på OpenId provideren).
Samt jeg kan allerbedst lide at MODTAGE et velformeret xml dokument, gerne efter et xml-scheme igen.
Som jeg skrev tidligere ville jeg se langt størrere potientiale i en REST service (SOAP er bloatet).
Det er så her jeg synes at brugeren ligeså godt kunne udfylde informationerne igen.
Hvis OpenId havde sikkerhed for ALTID at udlevere email og brugernavn ville jeg kunne se det brugbare i det. Ellers ikke.
Til services som kræver valid email til registration (der er cirka alting i dag).
Hvordan ville du ellers gøre det? Bemærk at det er et ønske til systemet, at man kan bruge en URL, som også bliver brugt til andre ting. Fx. sin hjemmeside.
Hvis du laver en begrænsing om at URL'en ikke indeholder andet end din openid, ryger en masse af openid's fordele.
Jeg synes jo at windcape.openidservice.tld skulle være den reele service, og ikke noget tilfældigt.
I forbindelse med egen hjemmeside skulle det så være mydomain.dk/openid som var refference til selve servicen.
Det ER et spild af resourcer at skulle crawle et HTML dokument for først derefter foretage endnu et request (det medfører også unødvendig load på OpenId provideren).
POST-requests er noget af det nemmeste at bygge op. Det er nok derfor nogle er fristet til at gøre det manuelt, det ville jeg måske også gøre, afhængigt af hvilke API'er jeg har til rådighed.Jeg kan bedre lide at sende et XML dokument der er valideret op imod et xml-scheme.
Samt jeg kan allerbedst lide at MODTAGE et velformeret xml dokument, gerne efter et xml-scheme igen.
Som jeg skrev tidligere ville jeg se langt størrere potientiale i en REST service (SOAP er bloatet).
Eksempel, at oprette en bruger på newz.dk:
Brugernavn, Password, Email, Navn
De mindste mængder informationer man har brug for. Det kunne jo være pratisk at hente det fra de nye brugeres OpenId.... hvis det altså var at man kunne stole på at deres provider ville give informationer ud.
Det er jo lidt ligesom hele kernen, et ID kort fra en given service som kan genbruges istedet for et password.
Jeg ville så hellere at windcape.openidprovider.tld ville retunere et XML dokument med informationerne. Det ville være langt simplerer.
Brugernavn, Password, Email, Navn
De mindste mængder informationer man har brug for. Det kunne jo være pratisk at hente det fra de nye brugeres OpenId.... hvis det altså var at man kunne stole på at deres provider ville give informationer ud.
Det er jo lidt ligesom hele kernen, et ID kort fra en given service som kan genbruges istedet for et password.
Jeg ville så hellere at windcape.openidprovider.tld ville retunere et XML dokument med informationerne. Det ville være langt simplerer.
Windcape (17) skrev:Ja, men det betyder at så skal en registration service først teste om data'en overhovedet er der, og så derefter renderer nødvendige input forms der tager sig af det manglende data.
Life's a bitch.
Når man så har fået input, så skal de valideres, og dem som ikke er valide skal markeres. Life sucks.
Windcape (17) skrev:Det er så her jeg synes at brugeren ligeså godt kunne udfylde informationerne igen.
Handler det ikke mere om hvad brugerne synes, end hvad den dovne programmør synes? Det er et spørgsmål om brugervenlighed. Hvis ikke du gider implementere noget af hensynes til brugervenligheden, så lad være. Du behøver ikke at læse de data. At de er der så andre kan bruge det er ikke en ulempe, det er en fordel.
Windcape (17) skrev:Det ER et spild af resourcer at skulle crawle et HTML dokument for først derefter foretage endnu et GET request (det medfører også unødvendig load på OpenId provideren).
Huh?
Din openid-url indeholder referencen til din openid provider. At den så potentielt også indeholder en hjemmeside er vel kun et problem, hvis du har en mega forside. Og i så fald, så kan du jo lade være med at bruge samme url til begge dele. (Eller lave dig en ordentlig forside.)
Windcape (17) skrev:Jeg kan bedre lide at sende et XML dokument der er valideret op imod et xml-scheme.
Jeg troede du ville have noget simpelt, som ikke spilder ressourcer?
jeg arbejder med XML til dagligt, og det er altså LANGT mere komplekst end den POST-request du synes var for kompleks.
Jeg tror du skulle tage at sove på det her, før du går alt for meget videre.
Jeg gider ikke forholde mig til alt det du skriver da myplacedk har summeret de vigtigste ting (navnligt at du vente til nytårstømmermændende har aftaget før du går alt for meget videre ;), men lige den her sprang i øjenene:
Nej, kernen er autentisering af brugeren foretages af en tredjepart. De ekstra attributes du får - og som du jo alligevel selv ville skulle spørge efter hvis du brugte password login - er bare en bonus.
Windcape (18) skrev:
Det er jo lidt ligesom hele kernen, et ID kort fra en given service som kan genbruges istedet for et password.
Nej, kernen er autentisering af brugeren foretages af en tredjepart. De ekstra attributes du får - og som du jo alligevel selv ville skulle spørge efter hvis du brugte password login - er bare en bonus.
Ja, man kan gøre det for brugeren. Det er også den eneste grund til at jeg overvejede det i første omgang. Enhver form for ekstra login og registration er jo ekstra arbejde.
Det er OpenId specfikationen/implementeringen jeg basher, fordi jeg synes det er elendig designet (og deres dokumention stinker).
Og det er jo fint at folk synes det er nice (og stadigvæk ikke bruger det), men jeg synes der er MEGET langt mellem udviklere som tager det til sig.
At implementere en service som OpenId skal være meget nemt for at folk overhovedet gider.
Med det komplexitet jeg har oplevet i deres specifikation ser jeg ingen grund til at tilføje det som standard i noget software jeg leger med nu.
Der er tydeligvis ingen logisk grund til at tilbyde det før du har et størrere sig ala. newz.dk pga. mængden af arbejde i det.
Og derfor betvivler jeg på at det kan blive særlig populært.
Det er OpenId specfikationen/implementeringen jeg basher, fordi jeg synes det er elendig designet (og deres dokumention stinker).
Og det er jo fint at folk synes det er nice (og stadigvæk ikke bruger det), men jeg synes der er MEGET langt mellem udviklere som tager det til sig.
At implementere en service som OpenId skal være meget nemt for at folk overhovedet gider.
Med det komplexitet jeg har oplevet i deres specifikation ser jeg ingen grund til at tilføje det som standard i noget software jeg leger med nu.
Der er tydeligvis ingen logisk grund til at tilbyde det før du har et størrere sig ala. newz.dk pga. mængden af arbejde i det.
Og derfor betvivler jeg på at det kan blive særlig populært.
Jeg havde en OpenID consumer (relaying party) oppe i løbet af 10-15 minutter sidst jeg prøvede vha. af PHP-biblioteket fra JanRain. Det er ikke svært. Men det er muligt at det mentalt opleves sådan hvis man er meget erfaren i bare at klaske et eller andet med password-login sammen.
Er der noget på dit site du ikke gør for brugeren? Jeg synes der er et eller andet galt med din tilgang til det her - det er som du forsøger at løse et problem med OpenID som det ikke er lavet til.
Windcape (21) skrev:Ja, man kan gøre det for brugeren. Det er også den eneste grund til at jeg overvejede det i første omgang. Enhver form for ekstra login og registration er jo ekstra arbejde.
Er der noget på dit site du ikke gør for brugeren? Jeg synes der er et eller andet galt med din tilgang til det her - det er som du forsøger at løse et problem med OpenID som det ikke er lavet til.
Jeg kunne skam også benytte et bibliotek, men normalt vil jeg teste nye protokoller selv før jeg benytter mig af dem.
De biblioteker der er udviklet er efte rmin mening, overdrevne komplexe. OpenId burde være et simplet HTTP POST request (plaintext som nu, eller xml), og ikke mere.
Jeg kan slet ikke forholde mig til det idioti af at skulle implementere en crawler i første omgang.
Man bestemmer lidt ligesom i designprocessen om man vil implementere næsten-overflødige features eller ej. Typisk set fra et tidsmæssigt synspunkt.
De biblioteker der er udviklet er efte rmin mening, overdrevne komplexe. OpenId burde være et simplet HTTP POST request (plaintext som nu, eller xml), og ikke mere.
Jeg kan slet ikke forholde mig til det idioti af at skulle implementere en crawler i første omgang.
Er der noget på dit site du ikke gør for brugeren? Jeg synes der er et eller andet galt med din tilgang til det herDet er vel massere.... bare se på f.eks. newz.dk, hvor lang tid vi skulle klage for at få en edit knap (som allerede var i systemet, bare ikke visuelt.)
Man bestemmer lidt ligesom i designprocessen om man vil implementere næsten-overflødige features eller ej. Typisk set fra et tidsmæssigt synspunkt.
Der hersker vist en del forvirring omkring OpenID.
Først og fremmest er Simple Registration (eller Attribute Exchange) ikke en del af OpenID, men udvidelser til OpenID. Det betyder også, at det ikke er et krav, at en IdP (udbyder) understøtter disse, selvom de fleste i dag nok gør. Da du ikke kan være sikker på, hvad IdP'en understøtter, bliver man selvsagt nødsaget til at validere dataene selv. Det er dog ikke det store problem, fordi det i dag vil være god praksis at have en almindelig brugeroprettelse, og at man så kan genbruge den formular, hvis de data, der modtages, ikke er tilstrækkelige.
Dernæst kan man aldrig stole på de data, man modtager. Det ville være smart, hvis man ikke behøver at validere en e-mailadresse andre steder end hos ens IdP, men en RP (altså fx newz.dk) har jo ingen garanti for, at alle IdP'er sender korrekt data. Jeg kunne sagtens implementere en IdP, der bare genererer e-mailadresser i det uendelige, og så vil det jo netop være forkert bare at stole blindt på den data, man modtager. Det er vel også en af grundreglerne ved validering, at man aldrig skal stole på noget.
De brugernavne, man vælger at sende med Simple Registration, kan selvfølgelig sagtens være i brug af andre (endda på samme IdP), men det er jo heller ikke et problem. Der er mange løsninger; man kan droppe de lidt gammeldags brugernavne, lade brugerens OpenID være brugernavnet, spørge om et nyt brugernavn, hvis det er optaget på RP'en, eller meget andet.
Med hensyn til den tekniske implementering af POST-forespørgsler, så giver det ufattelig god mening. Husk på at næsten alt kommunikation foregår fra slutbrugerens maskine, og det er altså ikke bare server-til-server kommunikation. Det betyder, at man skal tage højde for browserens egenskaber. Årsagen hertil er selvfølgelig, at brugeren skal kunne godkende og afvise enhver forespørgsel, og det kan de kun, når trafikken sker igennem deres egen maskine - ellers ville det selvfølgelig være mere elegant med REST.
Jeg er rigtig stor tilhænger af Convention over Configuration, men samtidig kan jeg godt lide, at OpenID i dag ikke er begrænset til at skulle hedde specifikke subdomæner eller have en bestemt mappestruktur, hvis det kun er for at lette de opslag, der laves. Det giver måske en forespørgsel mere, men det er altså ikke noget sammenlignet med, hvis en bruger skal igennem en oprettelsesformular, hvor der forespørges på billeder, CSS, JavaScript-filer og tilsvarende. Med bedre anvendelse af XRI (og XRDS) i fremtiden, kan man også minimere antallet af forespørgsler endnu mere.
I øvrigt ville en anden løsning stærkt begrænse anvendelsen af OpenID. Det er en styrke, at man i dag kun skal indsætte lidt HTML, da de fleste publiceringssystemer giver adgang til det. Hvis man skulle lave en særlig DNS-opsætning, så ville brugere af en tjeneste som Blogger være tvunget til at benytte dem som IdP, og så mister systemet sin decentraliserede fleksibilitet.
Jeg synes også, at de fleste biblioteker er modne, men det kræver en forståelse af, hvorfor protokollen er, som den er. Der er mening med det hele. Jeg er i øvrigt selv udvikler på DotNetOpenId, ligesom jeg står bag IdP'en LoginBuzz. OpenID er ikke besværligt at implementere, medmindre man vil skrive et bibliotek til det. Hvis man genbruger et sådant, så kan understøttelse altså ske med meget få linjers kode, der i øvrigt ofte følger med som eksempler.
Først og fremmest er Simple Registration (eller Attribute Exchange) ikke en del af OpenID, men udvidelser til OpenID. Det betyder også, at det ikke er et krav, at en IdP (udbyder) understøtter disse, selvom de fleste i dag nok gør. Da du ikke kan være sikker på, hvad IdP'en understøtter, bliver man selvsagt nødsaget til at validere dataene selv. Det er dog ikke det store problem, fordi det i dag vil være god praksis at have en almindelig brugeroprettelse, og at man så kan genbruge den formular, hvis de data, der modtages, ikke er tilstrækkelige.
Dernæst kan man aldrig stole på de data, man modtager. Det ville være smart, hvis man ikke behøver at validere en e-mailadresse andre steder end hos ens IdP, men en RP (altså fx newz.dk) har jo ingen garanti for, at alle IdP'er sender korrekt data. Jeg kunne sagtens implementere en IdP, der bare genererer e-mailadresser i det uendelige, og så vil det jo netop være forkert bare at stole blindt på den data, man modtager. Det er vel også en af grundreglerne ved validering, at man aldrig skal stole på noget.
De brugernavne, man vælger at sende med Simple Registration, kan selvfølgelig sagtens være i brug af andre (endda på samme IdP), men det er jo heller ikke et problem. Der er mange løsninger; man kan droppe de lidt gammeldags brugernavne, lade brugerens OpenID være brugernavnet, spørge om et nyt brugernavn, hvis det er optaget på RP'en, eller meget andet.
Med hensyn til den tekniske implementering af POST-forespørgsler, så giver det ufattelig god mening. Husk på at næsten alt kommunikation foregår fra slutbrugerens maskine, og det er altså ikke bare server-til-server kommunikation. Det betyder, at man skal tage højde for browserens egenskaber. Årsagen hertil er selvfølgelig, at brugeren skal kunne godkende og afvise enhver forespørgsel, og det kan de kun, når trafikken sker igennem deres egen maskine - ellers ville det selvfølgelig være mere elegant med REST.
Jeg er rigtig stor tilhænger af Convention over Configuration, men samtidig kan jeg godt lide, at OpenID i dag ikke er begrænset til at skulle hedde specifikke subdomæner eller have en bestemt mappestruktur, hvis det kun er for at lette de opslag, der laves. Det giver måske en forespørgsel mere, men det er altså ikke noget sammenlignet med, hvis en bruger skal igennem en oprettelsesformular, hvor der forespørges på billeder, CSS, JavaScript-filer og tilsvarende. Med bedre anvendelse af XRI (og XRDS) i fremtiden, kan man også minimere antallet af forespørgsler endnu mere.
I øvrigt ville en anden løsning stærkt begrænse anvendelsen af OpenID. Det er en styrke, at man i dag kun skal indsætte lidt HTML, da de fleste publiceringssystemer giver adgang til det. Hvis man skulle lave en særlig DNS-opsætning, så ville brugere af en tjeneste som Blogger være tvunget til at benytte dem som IdP, og så mister systemet sin decentraliserede fleksibilitet.
Jeg synes også, at de fleste biblioteker er modne, men det kræver en forståelse af, hvorfor protokollen er, som den er. Der er mening med det hele. Jeg er i øvrigt selv udvikler på DotNetOpenId, ligesom jeg står bag IdP'en LoginBuzz. OpenID er ikke besværligt at implementere, medmindre man vil skrive et bibliotek til det. Hvis man genbruger et sådant, så kan understøttelse altså ske med meget få linjers kode, der i øvrigt ofte følger med som eksempler.
#23
Jeg ved ikke hvad du koder i, men i PHP kræver det ikke meget mere end en linje kode eller to at udtrække værdien af et META-tag i et well-formed HTML dokument. Om det er overdrevet komplekst kan man diskutere.
Det er lidt som om du forventer at OpenID er lavet for at gøre livet lettere for webudviklere. Det er det ikke. Det er lavet for gøre login lettere og mere fleksibelt for brugeren. Hvis man vil forkæle sine brugere med den funktionalititet, så kræver det et stykke arbejde, ligesom alle andre funktioner.
Jeg ved ikke hvad du koder i, men i PHP kræver det ikke meget mere end en linje kode eller to at udtrække værdien af et META-tag i et well-formed HTML dokument. Om det er overdrevet komplekst kan man diskutere.
Det er lidt som om du forventer at OpenID er lavet for at gøre livet lettere for webudviklere. Det er det ikke. Det er lavet for gøre login lettere og mere fleksibelt for brugeren. Hvis man vil forkæle sine brugere med den funktionalititet, så kræver det et stykke arbejde, ligesom alle andre funktioner.
#25
Man plejer at udvikle APIs og standarder til udviklerer, og ikke slutbrugerer.
Derudover er man tvunget til at benytte regulare expressions siden internettet desværre ikke er tvunget over på valid XHTML endnu, så man kan ikke benytte XPath.
Ellers meget god post. Men det beviser jo også lidt at OpenID er lavet til at blive hacket på en side?
Jeg bryder mig bare ikke om at skulle stole på en crawler, virkelig ikke.
Og ja, teknologien er ikke til at kører det ordenligt via. javascript endnu, så jeg vil vente nogle år igen før jeg implementerer OpenID i forbindelse med bruger-oprettelse. Det er simpelthen ikke det værd i dag.
Man plejer at udvikle APIs og standarder til udviklerer, og ikke slutbrugerer.
Derudover er man tvunget til at benytte regulare expressions siden internettet desværre ikke er tvunget over på valid XHTML endnu, så man kan ikke benytte XPath.
DotNetOpenID burde vedlægge eksempler der ikke kræver 20 filer og 1000 linjers kode.Acro (24) skrev:Hvis man genbruger et sådant, så kan understøttelse altså ske med meget få linjers kode, der i øvrigt ofte følger med som eksempler.
Ellers meget god post. Men det beviser jo også lidt at OpenID er lavet til at blive hacket på en side?
Jeg bryder mig bare ikke om at skulle stole på en crawler, virkelig ikke.
Og ja, teknologien er ikke til at kører det ordenligt via. javascript endnu, så jeg vil vente nogle år igen før jeg implementerer OpenID i forbindelse med bruger-oprettelse. Det er simpelthen ikke det værd i dag.
Windcape (26) skrev:DotNetOpenID burde vedlægge eksempler der ikke kræver 20 filer og 1000 linjers kode.
Der kan være noget om, at der mangler en lettilgængelig guide til at implementere OpenID-understøttelse. Jeg synes dog ikke, at det på nogen måde er besværligt at overskue eksemplerne. Hvis du benytter ASP.NET MVC, så er det eneste, du skal bruge, faktisk denne controller (og et view, der indeholder et felt og en knap).
Windcape (26) skrev:Men det beviser jo også lidt at OpenID er lavet til at blive hacket på en side?
Jeg er ikke helt sikker på, hvad du mener. Kan du uddybe det?
Windcape (26) skrev:Jeg bryder mig bare ikke om at skulle stole på en crawler, virkelig ikke.
Det forstår jeg godt, men det er heldigvis også den dårligste af flere alternativer. På LoginBuzz inkluderer jeg de forskellige tags i HTML'en, men jeg medsender også en HTTP-header, ligesom jeg serverer et XRDS-dokument direkte, når Accept-Type indeholder "application/xrds+xml". De to sidstnævnte er noget mere sikre, så det bør en ordentlig IdP selvfølgelig også implementere.
Jeg er dog også enig i, at det er problematisk at have flere muligheder, fordi det så kan skabe forvirring og samtidig tilføjer kompleksitet til implementeringskoden. HTML-delen er dog et nødvendigt onde, hvis man gerne vil gøre anvendelsen bredt, da det alt andet lige er den løsning, der er lettest at gå til som bruger.
Windcape (26) skrev:Og ja, teknologien er ikke til at kører det ordenligt via. javascript endnu, så jeg vil vente nogle år igen før jeg implementerer OpenID i forbindelse med bruger-oprettelse. Det er simpelthen ikke det værd i dag.
Det kan jeg ikke helt følge. Der er utallige fordele, og det er med tredjepartsbiblioteker så let at implementere, at det ikke kan betale sig at lade være. Jo lettere det bliver for brugere at tilmelde sig eller at anvende et websted, desto større er sandsynligheden for, at de gør det.
Acro (27) skrev:Hvis du benytter ASP.NET MVC, så er det eneste, du skal bruge, faktisk denne controller (og et view, der indeholder et felt og en knap).
Nu havde jeg kun kigget de andre eksempler igennem, og gad ikke til at søge alle filerne igennem for lige præcis de linjer kode du præsenterer der.
Det ser en del mere overskueligt ud end de andre eksempler, så det kan godt være jeg vil benytte det til Auth.
Jeg synes bare det er meningsløst når man ikke kan stole på at få oplysningerne.Acro (27) skrev:Det kan jeg ikke helt følge. Der er utallige fordele, og det er med tredjepartsbiblioteker så let at implementere, at det ikke kan betale sig at lade være. Jo lettere det bliver for brugere at tilmelde sig eller at anvende et websted, desto større er sandsynligheden for, at de gør det.
Jeg synes stadig at noget lign. dette her ikke burde indgå i en specifikation:
The Consumer MUST be prepared to handle a response which lacks fields marked as required or optional.
Windcape (28) skrev:Jeg synes bare det er meningsløst når man ikke kan stole på at få oplysningerne.
Jeg kan altså ikke se hvordan det skulle være så meget anderledes, end at få input fra brugeren selv. Der skal du da også være klar til at modtage blanke felter, som ellers nok så tydeligt er markeret som "krævet".
Jeg synes det lyder både smart og nemt, for både bruger og udvikler:
Modtag de data der er, smæk det i dine form-data, vis formen.
Du kan evt. validere form-data med det samme, og springe skærmbilledet over hvis alt er OK.
Windcape (28) skrev:Jeg synes bare det er meningsløst når man ikke kan stole på at få oplysningerne.
Det ville være lettere, hvis man var garanteret data, men det er desværre umuligt med et decentraliseret system. Jeg synes dog ikke, at det er noget stort problem, når man bruger et framework som fx ASP.NET MVC.
Når en OpenID-forespørgsel går igennem (i Authenticate-metoden på din UserController), slår du op om din identifier findes i databasen. Hvis den ikke gør det, så lader du blot parametrene fra Simple Registration overføres til en Register-metode (dekoreret med AcceptVerbs(HttpVerbs.Post)), der så kan validere dataene præcis, som hvis brugeren angav dem hos dig. Så genbruges samme formular, og brugeren generes kun, hvis data mangler eller er forkerte.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund