nije mi baš jasna kakva je politika u vezi ove nove autentifikacije za Google Translate.
Prije je bilo dovoljno napraviti API key za pristup servisu, a sada treba i OAuth 2.0 client ID, koji mi nije baš jasan.
Ako se ne varam, to je autentifikacijski ključ korisnika. Tko u ovom slučaju izdaje taj ključ? Google verificira da se neki korisnik logirao na moju stranicu?
Tko u tom slučaju uopće može koristiti translate servis putem moje stranice …samo korisnici koje Google verificira?
Ili možda ja mogu sa svojim OAuth 2.0 ključem osigurati translate servis svim svojim korisnicima? No ako bi bilo tako, onda bi bio dovoljan API ključ, kao što je bilo nekada.
S druge strane ako je potreban OAuth 2.0 ključ po svakom korisniku, onda servis gubi podosta svoj smisao … jer to onda više nije backend servis koji mogu vrtiti po potrebi kad mi treba, nego zavisim od usera koji je aktualno verificiran … ili što već…
Uglavnom, skroz na skroz sam zbunjen što točno po novom Google zahtjeva za pružanje usluge svog translate servisa, pa ako može pojašnjenje, bit ću jako zahvalan.
Ono što me dodatno zbunjuje, da bi omogućio OAuth 2.0, moram i registrirati svoju aplikaciju:
What is the OAuth consent screen?
When you use OAuth 2.0 for authorization, your app requests authorizations for one or more scopes of access from a Google Account. Google displays a consent screen to the user including a summary of your project and its policies and the requested scopes of access.
… prilikom te registracije aplikacije, mogu se ograničiti samo na “svoje” usere, ili je pružiti uslugu i drugima …ali pri tome moram verificirati svoju aplikaciju.
Sve to ide u prilog mom shvaćanju da Translate servis mogu pružiti samo userima koji imaju Google račun, a ne da ga mogu koristiti nezavisno od usera kao nekakav backend servis za razne potrebe.
Doduše, kod mene je web stranica, ne aplikacija …Googleu je to valjda isto, mada mi nije jasno gdje to Google izlistava policies o nečijoj web stranici …
citajuci tvoje postove vezane za oba Google API-ja dozivio sam deja-vu. Prije 2-3 dana sam si postavljao ista pitanja samo sto je u mom slucaju bio Google Youtube v3 API koji gle cuda takoder zahtjeva OAuth 2.0
Istog sam misljenja kao i ti, sve gubi smisao jer ako ja zelim da moj korisnik uploada video na moj youtube kanal zasto bi se on morao ulogirati u moju aplikaciju preko Google-a???
Pokusao sam razne nacine:
credentials.json
API key + developer key
API key
nista od navedenog ne radi i na zalost ne mogu ti reci da sam nasao rijesenje nego sam samo htio napisati da sam u istom problemu i da mozda moramo potraziti druge platforme za svoje proizvode
Evo ga, baš sam proveo malo opsežniji razgovor sa AI-em i uspio mi je rastumačiti o čemu se radi.
Znači, od 12. travnja 2021. godine, Google je ukinuo mogućnost korištenja API ključeva za autentifikaciju, sada je obavezno koristiti OAuth 2.0 autentifikaciju za pristup API-jima.
Oni koji su već aktivirali ranije neke API ključeve, njima još vrijede …ali svi novi API ključevi zahtjevaju uz sebe i OAuth 2.0 ključ. (Nije još definiran rok kada će stari API ključevi prestati vrijediti samostalno, ali su najavli da će i to doći kad tad.)
Naime…
OAuth 2.0 autentifikacija pruža veću sigurnost i kontrolu nad pristupom resursima, jer omogućuje korisnicima da dijele samo one informacije koje su im potrebne. Također omogućuje bolje upravljanje pristupom i revociranje pristupa ako je to potrebno.
Znači, novi flow je sljedeći:
aplikacija mora tražiti od korisnika privolu za pristup njegovim podacima
to korisnika preusmjerava na Googleov screen koji objašnjava korisniku što ga aplikacija traži i korisnik tamo daje privolu. Sa tom privolom se generira OAuth 2.0
ovisno što aplikacija traži od korisnika, Google će morati manualno verificirati / odobriti aplikaciju. (Znači za neku osnovnu privolu, nema verifikacije aplikacije)
U suštini, za većinu stvari će stvar šljakati osim što komplicira “bespotrebno” development proces.
Treba imati na umu da OAuth 2.0 token ističe …pa će prije određenih radnji kao što su npr:
prevesti nešto korisniku
raditi bilo što sa mapom (geocoding i slično…)
ostali API servisi…
… prije toga će trebati dodijavati korisniku sa traženjem privole. Baš bedasto.
S druge strane, stvar nije skroz “bespotrebna” jer se ovako podiže sigurnost nad ključevima, da vam netko ne mrkne API ključ i napravi neželjeni trošak.
Ali da, API servisi ovime gube smisao da budu čisti backend servisi, neovisni od klijent strane i korisnika. Iako ruku na srce, to je rijetka potreba. Uvijek netko klikće…makar neki admin, pa se može koristiti njegov OAuth 2.0.
Jedino ne vidim da će se moći pristupati API-jima putem croneJob servisa, osim ako ne naprave neki extra ključ za taj case …ali time su vratili stvar na staro.
Što bi po meni bilo sasvim ok, da je na developeru izbor želi li sigurno koristiti svoje ključeve uz obavezno prisustvo OAuth 2.0 ključa, ili želi koristiti “single” API-key, na kojega mora paziti da mu ga ne kradnu.
Parametri:
key - ključ
source - jezik sa kojeg prevodim
target - jezik na koji prevodim
q - zahtjev za prijevod (može biti niz, može biti single)
I radi mi sasvim ok, i to sam nedavno pravio (prije 3 mjeseca):
U credintials → kreiraš api key, ja sam ga restrictovao po ip adresi, možeš po stranici i drugim fazonima radi sigurnosti.
Dok kod mail slanja, sam morao koristi OAuth2, tj. kreirat aplikaciju, pokupit ključeve, kreirati skriptu za korisnika kako bi se mogao prijaviti/dozvoliti pristup, sa tim dobijam token (jedan od tokena mi traje već 6 mjeseci), koji se ne briše tek tako, već samo na zahtjev korisnika, ili da ti izvršiš poništenje.
Samo idu različiti za svakog korisnika.
Dali si tad pravio i API key sa enable-anim translate servisom, ili si ga imao mozda od ranije?
Ja sam dao sve od sebe i bez OAuth2 nikako nije radio translator. Dokumentacija na translator APIu je po tom pitanju katastrofa … prakticki i ne kazu da treba OAuth … nego mi je to AI rekao.
Konačno sam ugradio i to OAuth traženje privole korisnika za acess_token i sa tim dodatnim ključem mi translator radi. Isto je endpoint na …/translate/v2.
Nesumnjivo je da me je ranije blokirao zbog nedostatka OAuth access tokena.
Osim toga, zanimljivo je da tebi toliko traje token … meni access_token za translator api traje 3600sec ili ti 1h.
A druga stvar koja mi je čudna, OAuth scope za request access_tokena spada pod sensitive scope… pa samim time je nesto i kompleksnija verifikacija za odobrenje aplikacije od strane Googla.
Dok s druge strane scope koji uzima od korisnika email i neke osnovne podatke, ne spada pod sensitive scope.
Pravio sam sve na novo, od projekta pa na dalje, jer sam pravio na računu direktora kompanije (povezao karticu njegovu i to), sve normala dodao i funkcionira.
A što se tiče tokena, nemam šta da ti kažem, traje već 6 mjeseci najmanje. Ali ono što sam primjetio jeste da istekne, ako se ne koristi često (u mene 1 dnevno se koristi trenutno OAuth2 za slanje mailova).
Također sam zaboravio napomenuti da koristim unpublished applikaciju, sa navedenim testnim mailovima kod OAuth2, jer mi i ne treba publično, bilo mi potrebno za 3 maila. Ali što se tiče OAuth2 samo da ti kažem da se slažem sa tobom u potpunosti, s… živo
