Here's what I'm trying to do:
When people log into our app, using Google Apps OAuth, they are automatically grouped within the app, by their organization.
We're already doing this with Slack, where a user logs in, says which team they want to log in from, and they are automatically grouped with other people from their Slack team.
With Google, it seems a bit more complicated. I do not need access to anything within the organization: no user list, no other e-mails, no files. All I need is the name of the organization, and some sort of unique identifier.
Is this even possible? I've been digging through this without much success: it seems like an admin from the apps account has to install or approve the app?
I'm getting the sinking feeling that this will have to be something setup via the Marketplace, but that's far from ideal from our perspective.
Can it be done?
What you want is the hd claim of the ID Token. This represents the "hosted domain" of the Google for Work user, i.e. their organization.
If you use the Google Sign-in library, you will be able to get the ID Token of the user, once you have that you can extract the hd claim. Try these docs: web, ios, android.
Related
Recently google has added multiple user support to the assistant so how would use the API to identify the person by voice?
It depends what you mean by "identify the person".
There is no way for an Action to get the raw audio, so there is no way for it to do voice printing or anything along those lines.
Although each voice has to be reported against a Google User ID, you do not have direct access to that user ID.
What developers do have access to is a UID that is sent along with each request to your fulfillment server. This UID is consistent across requests, although it can be reset by a user (for example, if they reset their Google Home). You can think of this the same way you think of an HTTP cookie - you can track the UID and, if you see it again, have reasonable assurance it is the same user that accessed it last time. This breaks down, however, for the "default" account on Google Home, since anybody who doesn't have an account will map to this user.
Beyond this, you can also use Account Linking to connect a Google Account consistently to an account in your own system. If you have sufficient authentication in place, or are using one from Google or Facebook for example, this can act as an identity.
There isn't an API for developers to identify users by voice.
I'm working for a company that displays content on big screens located on public places like GYMs or waiting rooms.
One client asked app that shows Instagram content from celebrities accounts, so I created one using the Instagram API.
The problem is that the app is in sandbox mode and it gets blank data.
It seems I can only show media from sandbox users (not Beyonce), when I submitted for review it was rejected because it doesn't meet the requirements.
Is there a way to make it work?
During tests I used a valid access token I found on internet, but I don't think that is a valid solution.
You are correct, when app is in sandbox mode you are only able to see data on Instagram from sandbox users which you have set in advance. You won't get any public data on Instagram in this mode.
According to the API, your app doesn't have the criteria required to get approved.
From the Permissions Review page:
Valid Use Cases
We will approve submissions of apps that fall into these use cases:
To help individuals share their own content with 3rd party apps
To help brands and advertisers understand and manage their audience and
digital media rights
To help broadcasters and publishers discover content, get digital > rights to media, and share media with proper attribution
They also listed use cases of applications that won't get approval and it seems like your app matches one of them:
Here are some examples of scenarios that will not be approved:
One-off projects. If you are an agency building websites or other integrations, note that we don't grant permissions to clients created
for one-off projects. If you are interested in building a product,
platform, or widget that will be used as a service across multiple
projects, then you may submit a single client_id that you can use
across multiple projects
...
To get approved you should modify your application to correspond with criteria, perhaps build multiple projects?
You can also try to pull down the data from this URL: https://www.instagram.com/<username>/media/
For Beyonce account, use: https://www.instagram.com/beyonce/media/
Lastly, the access token is unique per-app, so you can't be using a random one. Here is a tutorial on how to generate access token for your app.
We have an app and have built in IG integration but keep getting denied on our submission. We want to allow our users who have IG accounts to sign in on our app and then link their IG account. We show the IG icon and their IG name with a follow button so a user can gain followers on IG through our app. We need the follower list permission so that we can know if they are already following them or not and the relationship permission so that we can follow from our app. We have detailed the use case demo'd on a video but this is the only reply we continue to get. Any assistance would be great.
follower_list:
This permission (follower_list) does not support the use case you described in your submission notes, screencast and website. Please review Login Permissions (http://instagram.com/developer/authorization/) for a comprehensive list of permissions and valid use cases.
relationships:
This permission (relationships) does not support the use case you described in your submission notes, screencast and website. Please review Login Permissions (http://instagram.com/developer/authorization/) for a comprehensive list of permissions and valid use cases.
I'm running into the same issue with them declining my application for a valid use case.
I think it's because there wasn't enough information for them to validate the app, or the website isn't following their Platform Policy. I would read through it and make sure you're doing everything they want you to do. I would triple check what use case you picked and how you justified that your app falls into it.
It's also good to cover these, taken from Instagram.com:
Your submission should explain what does your app or company do, which
of the approved use cases your integration falls into, who will be
using your app, how do your user authenticate with your app, how you
use the API to power your integration, how does your product use the
data acquired from Instagram, etc.
I can see many related questions on SO, but none that answers exactly what I'm confused with.
I'm using Google Calendar API in a .NET desktop application that allows user to provide his/her username/password, logs in on his behalf and adds some events to the calendar. Now I want to do exactly the same thing for Tasks feature. I'm trying to use Google Tasks API for this, but have been told that I need to do some OAuth kind of authentication, and even before that, I need to go to my gmail account and set permissions and get my project "key" to enable it.
Now does every user of my application need to do these steps in their Gmail account? Or do I need to do this in MY gmail account once and then my application code will be able to use the generated project "key" to enable my users to add tasks to THEIR gmail tasks list?
Figured it out. For anyone having a hard time understanding this, here it is:
The "key" generation step needs to be done only once per application, not for each user who's going to use your application. To generate a key, login to your Google Account and go to Google APIs Console page. Click API Access button and that's where you can generate keys for different kinds of applications like browser apps, desktop apps, Android apps etc. After registration, you'll need to take Client ID, Client secret and API key from this page and put them into the code. Sample code (.NET) for task creation and several other Google features is available here.
Once your user runs your application, he'll be taken to his Google account in his default browser where he'll be asked if he wants to allow this application to write to his calendar/tasks list. This page will display your logo and description text too that you can provide at registration time. Once allowed, this step won't be required again in the next one hour (this may be adjustable, i don't know yet).
So I'm in the midst of creating a Facebook Connect enabled site. The site in question will leverage your social graph - as defined by your facebook account - to do social things (what is really not important here). Here's the big question I have:
Are people still rolling their own authentication heuristic when using something like Facebook Connect? That is, are newer (FBConnect) sites today providing only FBConnect as an authentication strategy, or are they pairing it with other auth strategies (such as Google Auth, Open ID, etc)? What do you think is the best way to go? With Facebook having over 300,000,000 users now, is having 1 authentication strategy (FBConnect) enough? Or is it proper netiquette to provide users other means?
Some of the references I have been looking at today:
http://www.kenburbary.com/2009/08/five-reasons-companies-should-be-integrating-social-media-with-facebook-connect/
Increased Registration - Data from Facebook states that sites that use Facebook Conect as an alternate to account registration have seen a 30-300% increase in registration on their sites.
• Citysearch.com – Daily site registrations have tripled in the 4 months since Facebook Connect testing began
• Huffingtonpost.com – Since integrating with Facebook Connect, more than 33% of their new commentor registrations come through Facebook
• Cbsinsider.com – Over 85% of all new user registrations are coming from Facebook Connect
http://www.simtechnologies.net/facebook-connect-integration.php
"according to the current statistics using facebook connect increases 30-40% user traffic as compared to non-facebook connect websites."
http://wiki.developers.facebook.com/index.php/Connect/Authentication_and_Authorization
Our research has shown that sites that implement Facebook Connect see user registration rates increase by 30 - 200%.
No Need to Create Separate Accounts
In general, it's not a good practice to force a new user to create a separate account when registering on your site with Facebook Connect. You'll have the user's Facebook account information, and can create a unique identifier on your system for that user.
Just make sure you understand what Facebook user data you can store, or simply cache for 24 hours. See Storable Information for details.
If the user ever deactivates his or her Facebook account, you have a chance to contact the user to request the user create a new account on your site. When a user deactivates his or her account, we ping your account reclamation URL to notify you of the deactivation. Then Facebook sends the user an email regarding the deactivation. If the user has connected accounts with any Facebook Connect sites, and if your site has specified an account reclamation URL, the email will contain a section with your application logo, name, and reclamation link, in addition to an explanation about the link's purpose. For more information, see Reclaiming Accounts.
http://www.chrisbrogan.com/how-facebook-connect-points-the-way-towards-velvet-rope-networks/
The Drawbacks
Though there are advantages to using Facebook Connect for integration, there are some drawbacks, mostly from the marketer’s point of view. If you build out a social network project using Facebook Connect, Facebook gets all the information and you get none. You don’t get a database of users. You don’t get a way to message people participating in your event, except for “in stream,” the way everyone else is using the app. You don’t have any sense of demographics, nor any control abilities to block trolls or other unwanted types.
Crystal Beasley "All of the FB Connect sites we have built so far have incorporated "standard" accounts as well, even with the added complexity of supporting dual login methods."
There are still people who use mySpace (myself not included), and I know a several people coming out of college that have completely deleted their FB accounts to get rid of information of them they don't want potential employers to find (I know, there are a lot easier ways of doing this). If there are people who for whatever reason do not want to have a FB account, at least give them the option of creating a private google account.
Using ONLY Facebook as the register/login-method seems pretty dangerous to me. If you had a regular user management system, with Facebook Connect to speed up the process from a user-perspective is a good idea.
The Problem is somewhere else
if you really want to leverage the social graph only facebook brings "pure" data
the graphs people build at e.g. myspace arent telling much about that person and its social env. - at google neither
if you are just heading for viral spreading prefer the plattforms that share the best (just facebook again)