Gmail API Oauth Approval been waiting almost 3 months - gmail

I have an application which has the ability to link to a Gmail account via OAuth for a client and send email from the system. I have created the OAuth authorization with Google almost 3 months ago. I received 2 emails from them over that time 1 was resolved within an hour the other was requesting a video which was already included in the original request.
Is google always this slow? I have called cloud support and did not receive any help. Anyone else had to wait months to get OAuth authorization from google?
Facebook and Microsoft were within a day.
Tried calling them cloud support (no help). Send them feedback on the OAuth console page. No reply. Replied to the email they sent a request for more information on but that was over 6 weeks ago no reply. I am trying to get access to send an email. This has to be one of the most common use cases with Gmail. Does not make sense that it is taking so long.
N/A. It is a web application using Gmail oauth2

The first few communications with google regarding verification went relatively quickly with 1-5 day response times. These were the "obvious error" ones. Once we resolved those, we received this on Mar 29:
Thank you for submitting an OAuth App Verification request. We
appreciate your patience during this review period.
The app verification process can take several weeks to complete.
Google will not take action against apps for non-compliance with the
new policy during the verification process if you are acting in good
faith to come into compliance. User access to your app for existing
approved scopes will not be impacted. All apps that have applied are
expected to fully complete the app verification process by May 15,
2019, with the remainder of 2019 to complete the security assessment.
So that is a suggested 6 week timeframe.
Have you received a similar email?
Also note: If your app is not currently available for public use ( or in development ), you can request to skip the verification process.
https://support.google.com/cloud/answer/9110914#skip
This has to be one of the most common use cases with Gmail. Does not
make sense that it is taking so long.
It might make sense in the context of the 2019 Restricted Scope security requirements and the level of chaos that is creating for developers, and therefor their support/verification team.

Based on FAQs, if your project contains multiple OAuth clients, Google needs videos demonstrating usage of restricted scopes for each of those clients. Failure to do so might be resulting in multiple communications. Removing unused clients from your project may help.

Email oauth-feedback#google.com and ask them for an update on your verification status.

Related

Docusign API Polling/Rate limiting doubts

Docusign eSignature API has a limit of polling 15 min in 15 minutes for requesting a unique url resources.
However in the documentation it is not explained if normal user behaviour is allowed , which is completely different from polling X in X minutes (e.g. clicking to view an envelope multiple times in a row).
Question 1
Is there a problem in Docusign if the same resource is called multiple times within 15 minutes in normal user actions?
There could be scenarios where the resource needs to be fetched much more frequently within 2 or 3 minutes, but almost 0 the rest of the day for that resource).
Common examples may be: asking for an envelope information, related entities and audit events within a short time span.
Question 2
Do all GET unique resource url have the 15 min rate limiting restrictions in eSignaturesAPI (envelopes, recipients, events, status, templates etc)?
Some documentation indicate only status related endpoints are poll restricted, other docs specify that all GET resources in the eSignaturesAPI are.
Question 3
One alternative for polling is to use Docusign Webhooks (Connect) as suggested in many articles, however to secure it with HMAC, it not possible in combination with oAuth.
The connect keys are associated with the user's account and not the client's app account (each user would have to setup their own keys, which is not feasible). One suggestion seems to be mTLS (which won't be an option).
What other ways exist to secure webhooks when using oAuth?
Wondering how other integrations have done it with the current webhook security limitations.
The reason that DocuSign cares about polling is because developers have built integrations that poll every 1 sec resulting in millions or API calls that clogs the servers.
It sounds like your integration is not doing polling.
Then all you have to do is pass go-live and you should be fine.
The last 20 API calls for your go-live review should adhere to the polling rules, make sure they are so. There's no way for DocuSign to know the intention of API calls, so the polling rule are strict, but they should not be hard for you to figure out.

Unable to complete Go Live process

I'm attempting to promote my development environment to live but the API transaction results keep failing at the 1st hurdle of '20 or more API transactions'.
I've pushed through about 40 envelopes (and signed them) from my development site so I presume that I've fulfilled this criteria.
The Docusign support team advised me to post the question here (!), so does anyone have any ideas?
Thanks,
C
The 40 envelopes must be done via your app, not via UI.
You cannot use a token from the token generator. Must use auth via your app (JWT, Auth Code Grant etc.)

Best way to plug users' gmail accounts into my system without triggering ominous warnings?

I am prototyping an automated messaging system with a few pilot companies and about 10 users. They want my system to send status emails on their behalf, from their gmail accounts. This can easily be accomplished when they enter their gmail usn/pwd into my system (it is AES 256-bit encrypted before being stored in the DB). The problem is that the first time my system tries to send a status email on their behalf, using their account, the message is blocked until "Allow less secure apps" is enabled. When they try again, it's blocked again, along with scary warnings being emailed to them by google saying that someone has their google password. Only after they click through that and verify that my system has permission to do this, all is good, no more warnings, and everything works.
I have been researching this and I have found 2 potential approaches for smoothing this process and avoiding the scary warnings to the users:
Enable 2-factor authentication in the google account, and use an app-specific password (per user I think??) to send the emails without any warnings.
Have my system use oauth2 with the gmail accounts so that google no longer considers my app "less secure".
My question is, what is the best approach, and how do I set this up? If my gmail users enable 2-factor authentication, can they store their code into my system, and my system uses that code for future auto-emails? Does it even work that way? My experience with 2-factor auth is that a code is sent to the user's phone each and every time. Is that not the case? Would a stored code on my server (1 per user) work over and over? Does it expire after a certain amount of time?
And my understanding with oauth2 is that my users would need to be actively logged in with their google account and somehow exchange tokens with my server, but I really don't know. Is there some way for my web server (PHP) to implement oauth2 in connection with gmail accounts?
In summary, what is the simplest way to send auto-generated gmails for my users who are paying for this service without triggering scary warnings from google? The volume of emails is low -- this isn't spam -- it's a status follow-up system for the workplace.
You are right on your second point; that is an easy way to accomplish your objectives. You'll first have to authorize your app with Gmail to work with OAuth. You can follow these links to learn how to implement authorization in your server, but you can also enter here to appreciate some examples. When you develop the authorization protocol, you can read the Gmail API to start working with your customer accounts.

Connect Google calendar api and api.ai

So here is what i am trying to do :
I built a bot with api.ai for my business that is hosted on my webpage and my Facebook page right now. Bot works well.
I want to push it to the next step by allowing my customers to make querys on my calendar, ask to book a specific time, see if available, if not offer other time similar, then make a booking.
I have been reading this thread and the great answer attached to it but i think my case is a bit different.
I was wondering if the bot could always have a token so every guests won't have to Auth to query the calendar ?
Obviously i am new to this, i have been reading the guide of google calendar api and api.ai but i don't really see how to do that yet. I guess there is a way to store a token somewhere and then just trigger the query with some specific intents but not to sure how.
I have also done the node.js quickstart guide of the G-calendar api, and it works fine if that helps.
Thanks for your help !
You will probably want to use a Service Account that is permitted to the calendar in question. Service Accounts are similar to regular accounts, but they are expected to do server-to-server communication only, so the method to create an auth token is a little different to keep it secure.
See https://developers.google.com/identity/protocols/OAuth2ServiceAccount for more information about using Service Accounts.
In general, you'll be using a shared secret to create and sign a JSON Web Token (JWT) you send to Google's servers. You'll get back an access token which you'll then use to call the Calendar API. The access token expires in about an hour, at which point you'll need to repeat the process.
There are libraries available to do much of this for you. For example, if you're using the node.js library https://github.com/google/google-api-nodejs-client, then it will take care of this for you (although you need to modify the key file - see the documentation for details).

Does Instagram approve client apps that want to show an public hashtag feed on their website?

I am working at a agency that used to add Instagram hashtag & user feeds on websites. My old applications still work until june this year (https://www.instagram.com/developer/changelog/). Then they will need to be approved by Instagram to get out of sandbox mode.
I understand that we need an valid access token with: public_content permission scope. I read many people having their applications denied by Instagram.
When I read their permissions review (https://www.instagram.com/developer/review/) on the developer part of their site I came across this question:
My company is working with multiple clients, should I submit one app
per project? No, we do not approve apps that are created for one-off
projects (e.g. a hashtag campaign, an event, a website). You should
use a single client_id across all your integrations.
Do they approve applications that reuses its client_id for several projects? For example if I would want to develop an application/client which whole purpose would be to show one public instagram hashtag feed on websites. Would that get approved by Instagram if I reused the applications client_id over several projects?
Your use case is not approved. So your client will not get approved to "go live". You can still make these tag requests in Sandbox mode, but you will only get results from your last 20 posts. This short article explains how the Instagram API works since June 1st.
If you can work around the 20-post restriction, you can use this tool to manually generate an Instagram API token with the necessary public_content scope.
I don't think so.
I have requested public_info permission for an application simialr to yours but "DECLINED"
Try to request the permission with a good screencast video on how to use it and might be work. who knows.
Regards.

Resources