Folosire google mail API

Salut!

Am urmatoarea problema. Am facut un script care citeste emailurile primite.
Am respectat pasii precizati de google in documentatie. Am salvat refreshToken-ul, am setat offline access, etc.
Scriptul acesta este la un url. Cand accesez url-ul din browser(si sunt si logat pe contul respectiv de email), merge.
Cand nu sunt logat, nu merge.

De ce? Ce pot sa fac in privinta asta?

poti sa citesti logurile cand rulezi acel script. sau ne poti pune aici codul.

nu primesc nici o eroare. nu am ce sa iti arat in log. pur si simplu sunt pus sa ma loghez in gmail.
lucru care nu ar trebui sa se intample.

exista vreo diferenta intre a folosi api ul de la google in browser, si in server?

exista vreo diferenta intre a folosi api ul de la google in browser, si in server?

Cred ca exista. Ce spune documentatia, poti sa ne dau un snippet de cod si linkul din documentatie.

Acesta este linkul corect pentru api? https://developers.google.com/gmail/api/quickstart/php

da, acesta este.

In doc spune:

If you are not already logged into your Google account, you will be prompted to log in. If you are logged into multiple Google accounts, you will be asked to select one account to use for the authorization.

Din ce inteleg eu, trebuie sa fii mereu logat

Nu e chiar asa. Asta e la inceput. Credeam ca ai mai facut implementarea asta. Merci oricum.

Off-topic: e puțin trist când încerci să interacționezi cu un serviciu de mail printr-un API REST in loc de SMTP/IMAP. Nu mi se pare cea mai grozavă alegere de la Google

3 Likes

yup, SMTP/IMAP este mult mai simplu. Ma gandesc ca este asa fost aleasa solutia.

de ce e trist? explica mi te rog. chiar vreau sa stiu
m am uitat la filmiletul de la google in aceasta privinta si aveau motive bune sa foloseasca un api in loc de smtp.

Este trist pentru ca deja exista un mod standard de a accesa un mailbox, vechi de 30 de ani, suportat de toate platformele, cu un ecosistem bogat in jurul lui de librarii, aplicatii client, protocoale afiliate etc. Ar fi putut, la resursele lor, sa extinda IMAP, ca sa acopere deficientele pentru use-case-ul lor. Care, din cate inteleg, sunt mai mult legate de drepturi de access mai fine-grained si accesul la unele concepte specifice GMail care nu sunt in IMAP. Dar au mai facut asta cu SPDY si HTTP/2, asa ca nu e chiar o propunere extraterestra.

E o situatie foarte similara cu cea de acum o saptamana sau asa, cand Facebook a anuntat Yarn, ca alternativa la NPM.

Pe un anumit plan, astfel de miscari fac parte din scheme de a extinde controlul firmei asupra platformei. Pentru ca pana la urma providerii mari chiar pot impune folosirea unui API de genul asta. Iar apoi il pot folosii ca o arma impotriva celor mai mici. Carora nu le ramane decat sa fie cetateni 2nd class, doar cu IMAP, si pe care nu merg toate aplicatiile noi de productivitate care folosesc API-ul Gmail/Yahoo Mail/QQ etc; sau sa stea sa implementeze si ei unul din API-urile deja existente, dar sa nu aiba control asupra lui.

4 Likes

multumesc mult pentru raspuns.