We have an Google client App which we are using in production currently and now we need to add a new scope(https://www.googleapis.com/auth/gmail.send) to it which is a sensitive one. For this we need to apply for verification and I am confused with the steps to do it.
The documentation says:
Show that the OAuth Consent Screen correctly displays the App Name.
Show that the URL bar of the OAuth Consent Screen correctly includes your app’s Client ID.
If my App is currently in production how can I add a sensitive scope to it and create a video?
Is there any way to create a video without taking my App off production in this scenario?
I went through this and this but didn't get the proper info for this scenario. But I feel this is very generic case and most of the organisations would have faced this.
If my App is currently in production how can I add a sensitive scope to it and create a video? Is there any way to create a video without taking my App off production in this scenario?
Your going to have to add the new scope to your project on Google cloud console, and then create the video showing your application using the sensitive scope as instructed.
make sure your browser window is sent to english
run your application and show the consent screen where it displays the scopes
and make sure to get a shot of the URL bar where your client id is displayed in the url.
Unfortunately this will probably knock your project out of verification and impact the fact that your application is currently running in production. As far as i know Google does not have any guidelines to existing verified in production applications requesting additional scopes.
If your issue is with development google recommends having a second project that you can use in the testing stage to develop on your application and then move to the new client when you are ready to go to production. This does not however answer how to request additional scopes without breaking your production client.
I am going to contact Google directly for some advice. I will let you know if i hear anything.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I am trying to create an IOS application. Part of it will allow upload of data to a Dropbox account that is hardcoded. I don't know how to do this part of my app without having a webpage show up that asks for authorization. Are there other ways to authorize an account without asking the user?
Don't do this. You're asking for a disaster.
Violates the Dropbox Terms of Service.
What happens when Dropbox suspends your account, your app breaks.
An API key you hide in the app could be compromised and exploited.
Look into another service intended for what you actually want to accomplish, Amazon's S3 is likely a good choice.
I would like to play videos inside an IOS web view with Cordova.
Videos must be available only inside this app.
I don't have any domain to restrict access, because it's a web view inside a native app.
Is there a way to use HTTPS with Javascript to authenticate with an API token, then play each video with this token?
Can anyone provide a specific script example to do the job?
It is not possible to do this in such a way that someone could not break it because an attacker could install a man-in-the-middle server with a certificate created using their own certificate authority and then sniff the data and use it outside the application.
However you could make it more difficult, by creating "single use" keys that you send to the device using the notification service every time a key is used, you invalidate it and create a new key for the next use. This would mean that someone trying to get around the system would find it very difficult to have more than one client using the content at any given time.
Given that that is the best you can do, why not simply have users authenticate themselves and not allow multiple sessions to be active for the same user?
I'm trying to understand how to wrap up the process of developing a package app that has access to users google drive data.
I started examining the "gdocs" sample but soon reverted to the "identity" because I just can't manage to make authorization mechanism work with my own client_id.
I'm currently using chrome canary and I can load the unpacked extension to chrome and make it work. (both identity and gdocs samples)
I am trying to change the client_id in the manifest to my own client_id but I just can't figure out how to make it work. I always get a "bad client id" response.
I could authorize web apps using "gapi.client.setApiKey(apiKey)" but not these packaged apps sample using "chrome.identity.getAuthToken"
I tried all possible combinations but the correct one it seems.
What is the correct way to authorize a packaged app while in development stage?
Do I need to upload it to Chrome Developer Dashboard first?
Can someone help?
Thanks.
Following the updated documentation for Identity API you will need to upload your application to the Developer Dashboard, in order to obtain the application key, and then copy it to manifest.json. That is how you ensure your extension ID is fixed.
Next in Google API Console you will select Installed application and Chrome application, specifying your extension ID (that is your application ID). That will generate a proper client ID that will be matching your application.
Please follow the first link for details.
I'm creating a simple iPhone app. The basic premise is that the app will display some data (That I provide online) on the application. The data changes over time, so the app has to draw the data from online and display it. I don't have a significant programming background so I don't want to use my own server.
Thus, I thought it would be significantly easier to just put the data into some documents on a Google account and then access them programmatically via the Google Drive API. I could then update the data in my Drive account and it would get updated in the application. The key here is that I am ONLY accessing ONE account that I own MYSELF. The users' accounts are not being accessed. Therefore the goal is to never have to log in manually. It should all happen behind the scenes, aka, it should look like a server, not a google doc.
With this in mind, it doesn't make sense to show the Google Accounts sign-in page to my users as the standard OAuth2.0 tutorial shows here:https://developers.google.com/drive/quickstart-ios#step_1_enable_the_drive_api
I should be able to access my own data by somehow hardcoding in my username, password etc. Google agrees here: https://developers.google.com/drive/service-accounts#use_regular_google_accounts_as_application-owned_accounts
The above link mentions a "refresh token" that I'm supposed to save. However, I have no idea how to build and save that token, or even for that matter, where to find it.
I've gone through both the basic tutorial and the Dr. Edit Tutorial for iOS, but they both assume that the application is accessing USER accounts not application-owned accounts.
I'm not asking for someone to write the code for me (though tidbits are nice), but if you can point me to a step-by-step guide or related sample code that would help me get started that would be awesome. I'll even come back and post the code that I use!
EDIT: Since I realized that the Google Drive API wasn't something I could use for what I am trying to do, I eventually found Parse which is an awesome tool that handles all the server backend for me and is free at the basic level.
Google APIs objective-C client library doesn't support service (application-owned) accounts, because they are supposed to be used by a server-side apps, instead of clients -- you shouldn't be distributing your private key as a part of an app.
If you would like to distribute content from a service account, maybe you should write a server leg to do the authentication and pass clients credentials in a secure way for them to talk to the API on the behalf of the service account. Or, use Web publishing to make documents universally accessible without authorization and authentication if privacy is not a concern.