cotestatnt / arduino-google-api Goto Github PK

Per this issue, the CORS policy changed for Google. I have received an API-key and updated the TOKEN.vue file where the requests seems to originate per the code below:

`getGoogleTokens() {
let payload = {
'code': this.authorization_code,
'client_id': this.client_id,
'client_secret': this.client_secret,
'redirect_uri': this.redirect_uri,
'grant_type': 'authorization_code'
};

  const headers = {
  	'Access-Control-Allow-Origin': '*',
    'Access-Control-Max-Age': '600',
    'Access-Control-Allow-Methods': 'PUT,POST,GET,OPTIONS',
    'Access-Control-Allow-Headers': '*',
    'x-cors-grida-api-key': '----key inserted here----'
  };

  const proxyurl = "https://cors.bridged.cc/";
  axios
    .post(proxyurl + 'https://oauth2.googleapis.com/token', payload, { headers } )
    .then(response => {
      let json = {
        'redirect_uri': this.redirect_uri,
        'scope': this.scope,
        'api_key': this.api_key,
        'client_id': this.client_id,
        'client_secret': this.client_secret,
        'refresh_token': response.data.refresh_token,
        'access_token': response.data.access_token,
      };
      let obj = JSON.stringify(json, null, 2).replace(/\n/g, '   \n');
      this.jsonToSave = obj;
      this.gotTokens = true;
      this.waitTokens = false;
  });
},`

When recompiled, it doesn't seem like the updates take as you can see from the Chrome output:
:authority: cors.bridged.cc :method: POST :path: /https://oauth2.googleapis.com/token :scheme: https accept: application/json, text/plain, */* accept-encoding: gzip, deflate, br accept-language: en-CA,en-GB;q=0.9,en-US;q=0.8,en;q=0.7 access-control-allow-headers: * access-control-allow-methods: PUT,POST,GET,OPTIONS access-control-allow-origin: * access-control-max-age: 600 content-length: 316 content-type: application/json;charset=UTF-8 origin: http://192.168.0.27 referer: http://192.168.0.27/ sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="99", "Google Chrome";v="99" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" sec-fetch-dest: empty sec-fetch-mode: cors sec-fetch-site: cross-site user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.82 Safari/537.36

Notice how the new header does not appear. Could this be a compiling issue - meaning it is not picking up the changes made to Token.vue when it assembles all the files? Is there elsewhere in the code base that needs to change?

Come da accordi apro questa "Issue" senza pretese, solo per condividere opinioni sulla realizzazione del progetto.
Partirei usando l'italiano, se necessario commutiamo in inglese. I commenti sono al solo scopo di chiarire alcuni aspetti ed eventualmente generare spunti di riflessione. NON è mia intenzione criticare l'ottimo lavoro svolto.

Base64

• I sorgenti in Base64 poco si integrano con il resto del codice C++, sembrano qualcosa di separato scritto in C. L'uso di classe C++ mi sembrerebbe più coerente.

GoogleFileList
Mi aspettavo più commenti, almeno nel .h. È una cosa che si aspetta l'utente della libreria.

La dipendenza da <Arduino.h>, almeno per l'header, è forse eccessiva. Sposterei l'include nel file .cpp.

I membri name ed id di GoogleFile potrebbero essere string, viceversa una inizializzazione a nullptr a mio avviso andrebbe comunque resa esplicita anche per loro e per isFolder.

_filesCount andrebbe esplicitamente inizializzata a 0, almeno per chiarezza.

La funzione clearList() non distrugge gli oggetti che compongono la lista linkata, ma si limita a cancellarne i riferimenti. Confesso di conoscere un C++ abbastanza datato, ma non ho trovato informazioni riguardo ad un eventuale garbage collector anche per C++, mi aspetto dunque che ogni oggetto vada distrutto prima di eliminarne i riferimenti.

Modificherei il prototipo di void addFile(GoogleFile gFile); in void addFile(const GoogleFile& gFile);. Inutile passare l'intero oggetto .

In void GoogleFilelist::addFile(const char* _name, const char* _id, bool _isFolder) i nomi preceduti da underscore sono fuorvianti (sono usati altrove per i membri della classe). In linea generale, in C sicuramente, tutti i nomi che iniziano per underscore sono da evitare perché riservati al sistema.

La costante 30 dovrebbe avere un nome parlante, che spieghi perché proprio 30.

L'allocazione fatta con new non ha il corrispettivo delete, ma questo è stato già detto prima.

Le due istruzioni strdup() allocano anche loro memoria mai rilasciata.

Doppio ;; alla riga #34.

Guardando le varie funzioni getFileXXX() viene da chiedersi se l'uso della lista sia la soluzione più comoda. Visto che non vengono mai tolti elementi non sarebbe più semplice l'implementazione tramite un array di puntatori a GoogleFile?

Non vedo applicazioni per la funzione getList() che restituisce l'oggetto in se.

Quando le classi contengono puntatori è bene controllarne la copia e l'assegnazione. Volendo impedire l'uso di copy constructor ed assignment si possono dichiarare le funzioni come private senza implementarle: GoogleFilelist(cont GoogleFilelist &obj); e GoogleFilelist& operator=(const GoogleFilelist& obj);. Questo evita "l'uso improprio del prodotto", anche non intenzionale.

The readme says there is a PHP script provided but where is it? I can't find it.

And thank you for sharing this project.

Log:

Gmail:29:50: error: no matching function for call to 'GoogleGmailAPI::GoogleGmailAPI(fs::LittleFSFS&, WiFiClientSecure&, GmailList&)'
GoogleGmailAPI email(FILESYSTEM, client, mailList);
^
In file included from /home/user/Arduino-Google-API-main/examples/Gmail/Gmail.ino:2:
/home/user/Arduino-Google-API-main/examples/Gmail/GoogleGmail.h:132:5: note: candidate: 'GoogleGmailAPI::GoogleGmailAPI(GoogleOAuth2*, GmailList*)'
GoogleGmailAPI(GoogleOAuth2 *auth, GmailList *list = nullptr);
^~~~~~~~~~~~~~
/home/user/Arduino-Google-API-main/examples/Gmail/GoogleGmail.h:132:5: note: candidate expects 2 arguments, 3 provided
/home/user/Arduino-Google-API-main/examples/Gmail/GoogleGmail.h:129:7: note: candidate: 'constexpr GoogleGmailAPI::GoogleGmailAPI(const GoogleGmailAPI&)'
class GoogleGmailAPI
^~~~~~~~~~~~~~
/home/user/Arduino-Google-API-main/examples/Gmail/GoogleGmail.h:129:7: note: candidate expects 1 argument, 3 provided
/home/user/Arduino-Google-API-main/examples/Gmail/Gmail.ino: In function 'bool configEmailer()':
Gmail:87:15: error: 'class GoogleGmailAPI' has no member named 'begin'
if (email.begin(client_id, client_secret, scopes, api_key, redirect_uri))
^~~~~
Gmail:90:17: error: 'class GoogleGmailAPI' has no member named 'getState'
if (email.getState() == GoogleOAuth2::GOT_TOKEN)
^~~~~~~~
Gmail:129:15: error: 'class GoogleGmailAPI' has no member named 'getState'
if (email.getState() == GoogleOAuth2::INVALID)
^~~~~~~~
exit status 1
no matching function for call to 'GoogleGmailAPI::GoogleGmailAPI(fs::LittleFSFS&, WiFiClientSecure&, GmailList&)'

This variable also gave error, redeclared:

const char warning_message[] PROGMEM = R"EOF(

Files: config.h and Const.h

Buongiorno!
e' molto insolito poter scrivere in italiano su github, ma una volta tanto mi fa anche piacere!!
Se comunque serve passare all'inglese... fammi/fatemi sapere.

Stavo cercando disperatamente qualcosa che mi consentisse di accedere a google drive da un ESP32 ed ho trovato questa libreria che mi sembra "spot-on".
Ho cercato di compilare il tutto usando PlatformIO, partendo da un primo esempio "AuthorizeOnly", e sono quesi riuscito... ma mi esce questo errore:

src/main.cpp:78:44: error: 'class FSWebServer' has no member named 'getRequest'; did you mean 'handleRequest'?
   WebServerClass* webRequest = myWebServer.getRequest();
                                            ^~~~~~~~~~
                                            handleRequest

in effetti, anche cercando "a mano", non trovo il metodo getRequest in FSWebServer.
Ho provato con l'esempio "GoogleDrive" e trovo esattamente lo stesso errore (oltre ad un altro).
Puoi darmi qualche suggerimento su come risolvere il problema? Non penso sia relativo a PlatformIO ma non si sa mai...
Grazie!

I'm trying to find a solution to simplify the authorization with Google and I think I found something interesting when using the option "Desktop app".

When using Google auth in desktop apps you pass a so called loopback IP to the Google server. For desktop apps this usually is localhost and any port. But we could use this loopback IP to pass the IP of our ESP device.

From the Google Docs:

The loopback IP address flow supports the use of a loopback IP address or localhost as the host component of the redirect URI where credentials are sent to after a user approves an OAuth consent request.

Usage of the loopback IP address is described here:

https://developers.google.com/identity/protocols/oauth2/native-app#step-2:-send-a-request-to-googles-oauth-2.0-server

I know that there is a deprecated warning but that is only for mobile apps.

Any thoughts on this? I will take another look at this after the holidays.