DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web dizajn i usability > Planiranje i usability
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

Planiranje i usability Planiranje, legalnost, privatnost, arhitektura, principi

Odgovori
 
Alati teme Način prikaza
Staro 07. 07. 2006.   #21
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

Postavio sam jedno polu teorijsko, polu praktično pitanje na SitePoint, ali ništa od odgovora. Uglavnom:

Citat:
I'm about to start working on API implementation for project management tool that I'm developing (see sig) and I have one question about API authentication.

I really like how Yahoo! does RESTful web services. Send request, get HTTP error or XML (JSON, YAML...) reply. But there is one thing that I don't really understand. Its token based authentication.

Process is pretty simple. In order to receive API key needed for authentication you need to go to website, login, set access permissions (read, read/write, levels) and when you hit submit you get redirected back to website that needs API key with generated API key. Than, and here is the part I don't understand, you need to request token. Later you use API key and token to use the service.

More details: http://upcoming.org/services/api/token_auth.php

What is the point of token? Both API key and token expire with time. Its much harder to guess two hashes than one, but still, if you have one you can retrieve other.

Any ideas. I have some, but still...
Izvinjavam se na lošem engleskom.
Ilija Studen je offline   Odgovorite uz citat
Staro 07. 07. 2006.   #22
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

ako sam dobro shvatio ti uzmes frob sa njihovog servera, i tim frobom mozes da generises veci broj zahteva tokom narednog minuta... ako bi sa zahtevima slao direktno frob onda bi neko mogao to da snifuje i da iskoristi u narednih minut taj frob da izda npr. zahtev koji kaze obrisi nesto i to bi proslo bez pardona...

ovako ti na osnovu frob-a generises token za svaki zahtev, i svaki put imas drugaciji token, ali oni tamo na serveru mogu da provere da su oni generisani pomocu njihovog frob-a, znaci mogu da te autentifikuju. Takodje (mada to nije nigde jasno objasnjeno) mora da postoji zastita da token moze da se koristi samo jednom, inace ne bi imalo smisla. Generisanje novog tokena za svaki zahtev (ali svaki put na osnovu istog froba) je uslov da to sve ima smisla...
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
Staro 07. 07. 2006.   #23
Ilija Studen
Direktor Kombinata
Invented the damn thing
 
Avatar Ilija Studen
 
Datum učlanjenja: 07.06.2005
Poruke: 2.669
Hvala: 44
119 "Hvala" u 64 poruka
Ilija Studen će postati "faca" uskoroIlija Studen će postati "faca" uskoro
Default

Citat:
Originalno napisao ivanhoe
Generisanje novog tokena za svaki zahtev (ali svaki put na osnovu istog froba) je uslov da to sve ima smisla...
Token se ne genriše za svaki zahtev, već za jedan API key. Iz dokumentacije:

Citat:
Once the frob has been used to get a token, subsequent calls to getToken with that frob will produce the token (if unexpired) regardless of whether the frob is expired.
A evo šta je rekao Cal Henderson (jedan od ljudi iza Flickr APIja):

Citat:
the api key identifies an application, while a token identifies a
specific user using a specific application.
Ovde mi više liči kao da se API key generiše za pristup određene aplikacije sa sve podešavanjima za dozvole, a token mu više dođe kao session ID.

--

Po meni cela priča baš i nema previše smisla kad oba ističu. Razumeo bih situaciju kada API key ne bi isticao. Dođeš, generišeš API key, remote aplikacija to sačuva i kasnije se pomoću njega "loguje" na sistem, dobija token (session ID) i na osnovu ranije podešenih dozola za API key ima određene opcije na raspolaganju.

Suma sumarum: implementiraću kako smatram da je najbolje (pasus iznad) pa ako se nađe neko sa kvalitetnim predlogom za unapređenje samog sistema (a nadam se da hoće), uvek možemo da ga popeglamo. API mi treba jer će svi asinhroni zahtevi iz skripte ići kroz njega i njegovo odsustvo je jedini razlog zašto activeCollab nema NI JEDAN asinhroni zahtev u sebi (za sada).

Poslednja izmena od Ilija Studen : 07. 07. 2006. u 10:00.
Ilija Studen je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Traži se programer za iPhone aplikaciju Franziskaner Poslovne ponude i zapošljavanje 0 08. 11. 2010. 18:25
[Java] Kako napraviti aplikaciju za mobilni telefon? Nemanja Avramović Programiranje 7 08. 03. 2008. 15:42
Importovati kontakt listu sa gMail-a u aplikaciju jasmanac PHP 1 28. 01. 2008. 19:41
Koju VoIP aplikaciju koristite? Dejan Bizinger Komunikacije 17 20. 03. 2007. 13:07
Kako zastititi perl aplikaciju? MorenoArdohain Programiranje 1 18. 10. 2005. 14:39


Vreme je GMT +2. Trenutno vreme je 07:36.


Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.