We migrating our app from the old Marketplace to the new one. And we faced with the problem like described here - Google Apps Marketplace app installation callback
But we have special app architecture, it allows to the same user authorize multiple domains. For example we have user(authorized with google +) admin#tester1.com and he needs to install app for following domains:
tester1.com where admin account is admin#tester1.com
tester2.com where admin account is admin#tester2.com
For tester1.com we can use licensing API and check if app is installed and who installed it. We already have authorized account admin#tester1.com and the same user installed app.
No issues for this scenario.
Next user needs to install app for tester2.com. In process of installation(at the marketplace side) user switching to new account admin#tester2.com and installing app.
When user backs to us, we using licensing API again and check if app is installed and who installed it. At this step app will be installed, but it will be installed by user admin#tester2.com which is currently not connected to our app.
For this scenario, how we can securely recognize that domain tester2.com should be linked to user admin#tester1.com? Any recommendations/advices?
Currently we see only one way - require user to authorize admin account for each domain that he wants to install with our app.
This appears to be a special case, and Google don't have any guidelines around how to handle it. Deciding how to charge for and provision your application is left up to the developer.
Related
I'm working on a Slack integration for our workspace that is within an Enterprise Grid. I have a workspace and I've created a Slack App with all possible OAuth scopes and have installed it in the workspace.
I'd like to automatically invite and remove users to our workspace using the app/bot. I should be able to do this with the Slack app/bot using the admin.users.invite and admin.users.remove API actions.
However, these two actions require the admin.users:write OAuth scope, which can only be used on an App that is installed organization-wide, so I can't use this scope on my workspace app:
The app requesting this scope must be installed by an admin or Owner of an Enterprise Grid organization. Also, the app must be installed on the entire org, not on an individual workspace.
Is there any other way I can have an automated system that invites/removes users to/from our workspace, without it being an organization-wide app? This is something I can do as a user through the Slack UI (and I'm not an organization admin, just a workspace admin), so one would think I should be able to do the same things via an app/bot that is installed and authorized to act on my behalf.
Unfortunately, the APIs currently provided by Slack are available for Org Owner & Org Admin roles.
The best course of action for you will be to collaborate with your org admins. Let them manage the app. It means you will not have access to token, but you can use the app as a user.
Create the app that will operate only on your workspace by using fixed teamId.
Ask the org admin to generate the admin token and update that in your app.
May be, if they find your app useful, it can be used across organization eventually.
We're trying to figure out how to submit to the marketplace, but are not sure what we need to do to alter our existing signup flow to accomodate the SSO requirement
Our app was not originally built to be a marketplace app so our signup flow is built for individual users. We are already following the OAuth2 flow as outlined on this documentation page. However, its not clear to me how this works for an entire org when installing from the context of a marketplace app.
Does the admin grant access to all the individual scopes we currently request for the entire org at once? Is there need for some sort of service account or something since we currently are requesting offline access? I'd like to understand what changes we need to make to our server's signup flow in or whether it is just a scope / manifest mismatch.
We currently request the following scopes from an individual user when signing up.
['email', 'profile' ,'https://mail.google.com/', 'https://www.googleapis.com/auth/calendar'],
Exact questions are...
What (if anything) do we need to do to alter our current individual-focused signup flow to accommodate a Google Apps Admin signing up their whole domain?
What scopes do we need to in our Google Apps Admin listing and how do they relate to the scopes we currently request from individuals?
There are not so many changes if you are already using three legged OAuth2.
The first change would be in you project in the developer console. There you need to enable the Marketplace SDK and make the necessary configurations. Here you will add the scopes that your app will request and those are the scopes that the admin will see when installing the app.
The admin will see the scopes your app is requesting, and he will decide if it's ok to install the application in the domain. If it is approved, then yes, the admin would grant access to the entire domain.
Offline access is part of the Oauth flow, after you receive the refresh token, you can continue refreshing the access token without having the user to grant access again.
It is not necessary to have a service account. The service account has two purposes:
To manage information related to the application. In this case the service account can have access to it's own drive to store and retrieve information that is related to the app functionality.
Impersonation of users. When using domain delegation of authority, you can use a service account to impersonate any user in a domain and act on it's behalf to make API calls.
To deploy your app, you also have to create a new project in the Chrome Web Store, with a manifest for Marketplace.
To answer your questions:
It's not necessary that you modify your current oauth flow. The admin will install the app in the domain, but when a user access to the app, the process for authentication is the same as individual.
The scopes in your Marketplace SDK configuration should match the scopes your app will use. This is mostly for security reasons, it wouldn't be safe if you install an app with some scopes and then the app uses different scopes.
You can try your app before actually deploying it by adding trusted testers in the chrome web store dashboard or in the Console API configuration. This way you can check if your flows and all the configurations were done correctly.
Hope this helps. Let me know if you have more questions.
We've migrated our app from the old marketplace to the new one. After a few days we've received an email that we don't comply with an SSO policy - the user is not recognized after he installs the application.
In the old app we had a specific setup link, that was opened for the user after he installed the app - thus making him recognizable. Is there such a function in the market? Is there some sort of a callback for the installation event in the new marketplace?
P.S. the guy from Google told me to post technical questions on Stackoverflow and that "Our developer relations team monitors that forum and will be able to assist you."
EDIT:
There's the Additional app setup link in this after-installation popup (which clearly no user will click):
Is there a way to call the URL that of the Additional app setup in the background, without needing the user to click an obscure link?
That was an intentional design change which is different than how it used to work in v1 of the marketplace.
If you need interactive setup, best thing to do is put in a check on login to see if the domain has been configured. You can use the licensing API to check for a marketplace install record or directory API to check user permissions if those matter for your use case.
If you just need to run a background task, you can periodically poll the licensing API to detect new installations of the app. This shouldn't be done too often, so if you need to do things before a user logs you're still better off going with a check on login to route them to the setup flow as needed.
I'm developing a google apps marketplace app. There's the Test install flow button on the dashboard, but I'd like to test installation on another domain of ours - to see that permissions, token etc. work as expected. Is there a way to install an (it's non published yet) on a domain which is not related to development?
Found a solution, this was surprisingly straightforward, but it worked for me:
Open two browser windows, one for your dev account (dev.com) and one for the domain you wish to test on (test.com)
In you dev account, go to the dashboard and click the Test installation flow button
In the popup that you get, go to the address bar and copy the link
Now go to the browser with your test.com domain, and enter this address
You'll be asked to login, and then you'll get the consent screen
You should now see the app in your test.com`s marketplace apps list
You can do this by creating a new application in the chrome web store.
Make sure that you create this application in the web store with an account that belongs to the given domain. Next, restrict access to your domain.
Finally, you can install the application on the domain.
I have created an app in the Google Apps Marketplace SDK and now I have the "Test Install Flow" button, which is fine,. however, when I click it, a popup for business account signup appears and asks me to set up a real Google business account. How can I simply test it with the same developer account I have?
Had the same issue. It occurs when you first log in to Google with a non-Google Apps account (like a free Gmail account), after which Google Apps accounts are added (i.e. are logged in).
As Ben Clifford suggests in comments, one needs to be signed in first with a Google Apps account (after logging out completely). As a best practice, use Google Apps accounts in one web browser, and free Gmail account(s) in a different browser - to avoid further issues.
You have to test it with a Google Apps account. Apparently yours is not one of those, so they're asking you to sign up. If you have a different Google account that has Google Apps already, you can add that account to the project in Permissions -> Add Member, and then use "Test Install Flow" while logged in as that other account.