towfiqi / serpbear

Search Engine Position Rank Tracking App
https://docs.serpbear.com/
MIT License
1.45k stars 146 forks source link

Broken Google Ads Integration #216

Open anaimx opened 6 months ago

anaimx commented 6 months ago

After retrieving developer token, and test account ID, I tried to do Google Ads integration with "Test Google Ads Integration".

Tried with multiple account, still have the same issue.

The message:

Failed to connect to Google Ads. Please make sure you have provided the correct API info.

Btw, I deployed Serpbear using Docker inside Ubuntu droplet in Digitalocean.

carsaig commented 6 months ago

Confirmed. BTW: the integration on google cloud side requires a full TLD, not a local IP for the redirect URL. Sure, http://localhost:1234 will cut it, but that implies the app is running on a machine propagating localhost on the local network (in my case it does not as it runs on my NAS and my local DNS is not provided by the NAS). Using something like http://searpbear.local:1234 doesn't work either. Only TLD endings accepted. So I configured a TLD on my reverse proxy, patched the required ports through my firewall and tried again. No success. Google revokes the authentication request with Error 400: "redirect_uri_mismatch" Request details: "redirect_uri=https://serpbear.tld.xyz/api/adwordsflowName=GeneralOAuthFlow"

"You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy. If you're the app developer, register the redirect URI in the Google Cloud Console."

This leaves me without a useful answer. My URI is valid. And SerpBear is reachable on this domain. My guess is, that the request going out from SerpBear is deprecated. I haven't checked the outgoing request with a proxy yet, will do later and see, what the google docs expect as a request. https://developers.google.com/identity/protocols/oauth2/web-server?hl=de#authorization-errors-redirect-uri-mismatch

UPDATE: The issue is related to routing on my NAS (Synology). It's probably header related. I'm no Expert. The inbound requests get patched through the reverse proxy to the docker container running on the NAS. That's where things go sideways. As the reverse proxy works in my alternative scenario it can only be the internal route to the docker container spoiling the fun. However, running it locally on a RPI5 did the trick. The request inbound still hits the NAS reverse proxy, but then I forward them to a local IP, respectively my RPI5 where the app is running on, instead of the containers running on the NAS itself. The RPI runs on a dietpi distro and doesn't cripple the headers as Synology does. Issue solved. Not nice, just a workaround but it does the trick until I find out what is going on with the routing behind the NAS reverse proxy...

anaimx commented 5 months ago

I have no issue with connecting to GCP, since I'm using TLD in my ubuntu droplet, but stumbled in the Google Ads integration stage. Hope that @towfiqi can help assist.

bretmlw commented 5 months ago

I'm also running into the same issue, I'm using an FQDN for the install and redirect URL too. I wish I had come here earlier! Though I'm not sure if my error is exactly the same (I am also using this in a container, albeit k3s on TrueNAS Scale). The SerpBear logs report:

[ERROR] Google Ads Response : User doesn't have permission to access customer. Note: If you're accessing a client customer, the manager's customer id must be set in the 'login-customer-id' header. See https://developers.google.com/google-ads/api/docs/concepts/call-structure#cid

alexionegit commented 5 months ago

Hello dear friends,

I am unsuccessful in integrating SerpBear v 2.0.2 with Google Ads. The app is hosted on my personal server on a https subdomain proxied by Cloudflare.

I get the redurect_uri_mismatch error and if I refresh that page I get the invalid_grant error.

I have tried to have the Oath consent screen in test mode and as well as published.

I read and tried most of the fixes suggested on these pages.

NEXT_PUBLIC_APP_URL = Authorised redirect URIs in Google Cloud Platform, Credentials

I do not even know what to do next.

Could you please help me?

Thank you! @towfiqi

Alex

teddyfresco commented 1 week ago

Hi , I can confirm that for local servers it seems it doesn't work, I've followed the guide here https://docs.serpbear.com/miscellaneous/integrate-google-ads until step 3, but the "Authorized redirect URIs" phase requires a TLD... Tried with localhost, but the access was blocked by Google"device_id and device_name are required for private IP: ...". Tried filling in my windows host file with testlocal.com and it got accepted as an authorized URI, but after filling in SerpBear's Step 1: Connect Google Cloud Project and authenticating it went through all the steps, until I got this message, seemingly from SerpBear: "Error Saving the Google Ads Refresh Token . Details: redirect_uri_mismatch Redirected URL: https://testlocal.com:3008/api/adwords. Please Try Again!" Don't know what else to do...

towfiqi commented 1 week ago

@teddyfresco I have connected the Google ads account multiple times with localhost URLs without any issues. Not sure why you are getting this message. Can you please try https://nip.io/

teddyfresco commented 1 week ago

@teddyfresco I have connected the Google ads account multiple times with localhost URLs without any issues. Not sure why you are getting this message. Can you please try https://nip.io/

Hi towfiqi, thanks for your answer, just applied your suggestion (again with domain set on host file, and reverse proxying the local ip:port to nip.io, setting URI 1 to: https://nip.io:3008/api/adwords) but after trying authentication, this is the exact error: Error 400: redirect_uri_mismatch You cannot access this app because it is not Google OAuth 2.0 compliant. If you developed the app yourself, record the redirect URI in Google Cloud Console. Get details: redirect_uri=http://nip.io/api/adwords flowName=GeneralOAuthFlow Tried also with serpbear.mydomain.com with a domain of mine, obviously adapting settings, same result. I'm using caddy as a reverse proxy, could it be the culprit? It seems to be working for other purposes...

towfiqi commented 1 week ago

@teddyfresco Ensure your reverse proxy is setting X-Forward headers.