I'm currently developing a gmail add-on and am hoping to allow a few users internal to my team to test out the add-on prior to a public release. I was following the documentation here from google that states
You can allow other users to test the add-on by sharing the Apps Script project with their account (read access is required) and then prompting the users to follow the above steps.
I assume that 'read' access is equivalent to 'view' access, and have given a user 'view' access to the project.
The problem I'm running into is that even with 'view' permissions, users aren't able to do a test deployment and install the add-on to their gmail account. The blue 'Deploy' button simply isn't visible. Any ideas on how to get my add-on into a few users hands before publishing, but without giving them edit privileges?
One way to do it is to have the users copy your script and deploy it.
Another is to publish the Add-On privately and you would have control over what version of the Add-On your test users are seeing. For this your users should be of the same Google Workspace domain
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'm working on development of web application that communicates with GSuite services (e. g. Gmail and Google Drive). Bunch of people currently use my application. I have 2 OAuth 2.0 applications created in my GSuite organization: one used for development and testing purposes (let it be MY_DEV_APP) and another one for public usage (let it be MY_PROD_APP). Recently I've got a message from Google team that my apps should be verified till the end on May 2019. So I went through all the requirements described in documentation and made changes in order to meet them. After that I sent MY_PROD_APP application to verification but not the MY_DEV_APP application. MY_PROD_APP gets verified and is still used publicly. However MY_DEV_APP application left unverified and now I see that all the scopes are removed from it (looks like it was disabled by Google)
so that I can't use this application anymore.
As documentation states:
An unverified app is a web application or Apps Script that requests a sensitive OAuth scope, but hasn't gone through the Google verification process. Users of unverified apps or your test builds might get warnings based on the OAuth scopes you're using. This is to protect users and their data from deceptive applications.
OAuth 2.0 application can be created for internal usage only in GSuite or with limited access AFAIK. But currently I can't figure out how can I do this. Could you please provide detailed manual how to do this? How can I create OAuth 2.0 application in GSuite for internal usage only without mandatory verification?
Creation process of G Suite application for internal usage (inside your organization) only is almost the same as for the regular application. All the steps for creation and publishing G Suite application is described in G Suite Marketplace Guide. In order to create G Suite application for usage inside of single organization and omit verification process you should set Visibility option value to "My Domain" (application will be only available to users inside your domain) during configuration of G Suite Marketplace SDK as described here. This option can't be changed after saving configuration so it should be set during initial setup.
After publishing your internal application it can be found in G Suite Marketplace section where all applications for your domain are located.
Here is a short list of steps for creating of G Suite application based on information from G Suite Marketplace Guide:
Create new project in Google API console. Set name, project ID (project ID can't be changed after project creation and it should be unique) and project location (as a rule this is current GSuite domain and it can't be changed at this point).
Configure consent screen as described here. Here you can choose required scopes for Google APIs and authorized domains. Set "Internal" Application type so that only users with a Google Account in your organization can grant access to the scopes requested by this app.
Setup OAuth 2.0 client ID. After saving the configuration you will see popup with client ID and clien secret. Copy and save them somewhere. Please note that these value will be later available under creadentials tab for given application (OAuth 2.0 client IDs > Client ID for Web application item) at any time.
Setup service account key. After that JSON file will be downloaded where you can find private key and other information that you need to use your application.
Add APIs & services that you application use (e. g. Gmail API, Google Drive API). G Suite Marketplace SDK is required here.
Setup G Suite Marketplace SDK and publish you application as described here. Choose "Public" Visibility option to allow your application to be found by and used by any admin from the G Suite Marketplace. Otherwise you can select "My Domain" visibility (also known as Private visibility) that indicates that only admins in your domain can find and install the app from the G Suite Marketplace. If Enable individual install is also checked, then single user can find and install the application as well as well as it can be installed by organization admin.
I don't know the version of the G Suite account you have but I would suggest to create an App Maker application if is for internal use since no one can access if is from outside the domain.
To get your application verified I would suggest to send a verification request from the consent screen of your project, the first time you may send the verification without the scopes your application needs then it should be approved for you to add the scopes that your application use in order to get these verified one more time. Usually since the very first verification request by adding all the scopes you should have your account verified.
If you are still having problems by getting the verification I would suggest to contact the G Suite Support and request to speak with the API team, they don't have direct access to approve or reject the applications but will be able to help to provide you a guideance or may request internal help for you.
To know more about Google App Maker you can check here https://developers.google.com/appmaker/?hl=es-419 and https://gsuite.google.es/intl/es/products/app-maker/.
I hope this information is still useful. Greetings.
I have been making a slack app for the users on my workspace. It is a sidebar that adds slack messaging functionality to our website, so that we don't have to leave the site to see our slack messages. I am having trouble trying to get bearer tokens for each user.
What I have been doing so far is following the Slack OAuth 2.0 Authentication flow in order to receive tokens for users. This worked for me in testing and it works for some of our users currently. However, some users see something completely different.
Instead of asking them for permission to use their slack profile, the slack.com/oauth/authorize is telling them they can't install the app because it isn't listed in the slack directory. However, this page should not be installing the app to the workspace. It is already installed. It should just be asking for their permission to use their profile.
Am I using the wrong page? Did I miss something I need to do?
The Oauth process in Slack is not only used to get an access token, but also always is regarded as installation process for the respective Slack app. So your users are basically (re-) installing your Slack app each time they run through the Slack Oauth process. This is the standard behavior and can not be changed.
If you want to continue using this process you can simple enable installation for your Slack app on the workspace for all users (click on approve on the app management page of your workspace for this particular app) and then your users will no longer get the error message. You may also need to enable distribution of your Slack app on the app management page.
Btw. installing the same Slack app by multiple users is the default approach for getting access tokens for individual users. Slack calls those additional installations "configurations" and you can see them listed on the app ages for your workspace.
Note that Slack access tokens obtained from the Oauth process do not expire. So you only have to let the user install your Slack app once and then store the Slack access token for the next time.
How can I add a configuration page for my slack app?
example: asana has an add configuration button which leads to a page which we can use to then connect the slack user account with asana account
Several Slack apps (e.g. Twitter, Google Calendar) provide a configuration page after installation into Slack. However this feature seams to be available only to commercial partners of Slack, but not as a standard feature for every app developers.
Developers need to implement it by themselves with an external app / script that is linked the Slack app and store the configurations in their own database.
See also this answer for a full explanation on how this works.
Looking on the official Slack Plattform Roadmap for Developers this feature might be implemented in the future under "Install apps from within Slack".
Update:
You can now use Dialogs to create something similar to configuration pages. It allows you to open a custom modal window with up to 5 inputs (text or drop-downs). Its still not the same as having a full configuration page like the internal Slack apps have, but its a huge step forward and might be sufficient for many cases.
I'm using using Jenkins' Google login plugin for user authentication. I've installed and configured the plugin as mentioned in documentation and working as well. However users from only one google app domain can login to jenkins and access it(jira link). We have users from couple of domains. Another issue with this plugin is- not able to control user authorizations. All users can do anything. I've attached screenshot showing jenkins google login plugin configuration
Is there any workaround or alternative for this?
Since version 1.3 (November 21st, 2016) the google login plugin allow multiple domains separated by comma.
Check the changelog:
https://wiki.jenkins.io/display/JENKINS/Google+Login+Plugin
And the PR:
https://github.com/jenkinsci/google-login-plugin/pull/3
According to Google Cloud Platform that's not possible and the only suggestion is to set "Allow anyone with a Google account" if you are using multiple domains:
Understanding authentication for your end-users
...
Allow only members of a Google Apps domain to access the application. This is ideal for “intranet” applications where access is
limited to the users in your domain.
This method can only restrict to a single Google Apps domain. This
will not work if you use multiple domains with Google apps. If you are
using multiple domains, then select “Allow anyone with a Google
account” and extend your application code to restrict access to
end-users that are from your set of Google Apps domains. Your
application can use the value of the user_organization of the
signed-in user (rather than parsing the email address) to determine
the domain name of the user.
Also, this issue is already registered in https://issues.jenkins-ci.org/browse/JENKINS-32536 and it is still Open and Unresolved