Hello,
Thanks for getting back. Yes that is was I figured sadly. Honestly though,
I'm happy with any solution that makes it so that the refresh token doesn't
need to be retrieved every week. Security implication are a concern though,
which is why I was unsure about publishing the app.
[image: 2022-11-30 09_09_00-Cortana.png]
Do you know if there is a way around this?
I've already looked into automating the refresh token retrieval process. I
got quite close, but there is just one roadblock here that I can not get
past. It's a very technical issue;
During the OAUTH process, the user (me) picks their account from the list
of Google accounts in their browser, then acknowledges that the app is
unverified, and then agrees to the app permissions.
That last step, "*then agrees to the app permissions*" is where the magic
happens.
At this stage, my browser generates a list of unlabeled data points (likely
obfuscated because the protocol designers were hoping to prevent people
from doing exactly this).
It looks a lot like this:
[0, "ChR!490t-wqqnpg5nb.fjw044qh", True, True, None, False, 0, 1, 1, 0]
This blog post
<https://kovatch.medium.com/deciphering-google-batchexecute-74991e4e446c>
makes mention of the array I am talking about, "f.req", but for a different
process entirely. In the blog post, "f.req" is provided different variables
than in my case, so it is not very helpful.
Once the browser generates that list, it sends it to your authentication
server and then your authentication server responds with a URL. That URL is
already pre-setup by your server, and it contains the refresh token within
it. My browser redirects to the URL and I get the refresh token printed out
in my PC console.
For my case, I was able to reverse engineer most of the data points, except
two. That second entry that begins with "!ChR", I can not figure how to
reverse engineer its production. If I can figure this out, then I could
fully automate the process of getting refresh tokens by making my program
just create the array and send it to your server (same as my browser does
in the manual process). Alternatively, I could set up a "macro" like
protocol to interact with the authentication screens same as a user would.
I don't really like this idea too much, but perhaps it is the best option.
Unless you think there is a way around making the app available to anyone
with a Google account. If there is a workaround for that after publishing,
then maybe that could work too.
On Monday, November 21, 2022 at 6:50:39 AM UTC-8 adsapi wrote:
> Hello,
>
> I happened to bring this up with one more coworker and I have what I hope
> may be some good news.
>
> If you mark your app as external (even though it is technically internal),
> then the following restrictions would apply:
>
> - You would be limited to 100 total refresh tokens.
> - Your app would have a warning on the OAuth consent screen stating
> that the app is not verified.
>
> I believe that, in your case, neither of these restrictions should
> actually pose a considerable problem, since you effectively only one one
> refresh token that's generated at development time, and your internal users
> won't actually need to see the OAuth consent screen at all.
>
> If that's the case, it sounds like marking the app as external is actually
> a solution to your problem. You don't need to verify your app if you don't
> ever plan on having external users log into the app, and you're okay with
> that "not verified" warning.
>
> Upon researching more, the idea of "internal" only applies to Google
> Workspace because there's no way on our side to verify whether a given user
> is internal or external without the Google Workspace framework.
>
> Hopefully this workaround eases some of the load on your configuration.
>
>
> Regards,
> Mike, Google Ads API Team
>
> ref:_00D1U1174p._5004Q2ewsYl:ref
>
--
--
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog:
https://googleadsdeveloper.blogspot.com/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
You received this message because you are subscribed to the Google
Groups "AdWords API and Google Ads API Forum" group.
To post to this group, send email to adwords-api@googlegroups.com
To unsubscribe from this group, send email to
adwords-api+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/adwords-api?hl=en
---
You received this message because you are subscribed to the Google Groups
"Google Ads API and AdWords API Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to adwords-api+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/adwords-api/f9fc7e01-9282-43d6-8511-ada14de36965n%40googlegroups.com.
