Google published that they are testing a feature that allows you to sign in simultaneously to multiple Google accounts in the same browser.
Any idea how would that be implemented ?
I don’t have any inside info on how multiple accounts are actually supported, but here’s what I presume:
Your cookie holds a security token, just like in the old days.
The security token now maps to a set of signed-in accounts on the server.
I’d guess there’s a notion of an active account among this set.
When you go to a Google service that implements multiple-account support, the service pulls down your active account and drops you into that account by default.
Then, you get presented with some UI that lets you toggle between your other signed-in accounts or lets you sign into a new account.
Related
I wrote this same question to #Linkedin support service and I was redirected to this link where they indicate to ask questions in Stackoverflow.
We are developing a mobile App for the Polytechnic University of Madrid and we plan to expand to other Universities in the future. This aplication will need in a first instance OAuth via Linkedin. It will also need to allow the authenticated user to send connection invitations to other users contained in a list. For creating that list of users, it will be useful if the admin of the system could search in a bar similar to the one which Linkedin has, write a user name and select it, retrieving its user ID or what is needed to identify the invitation destination.
Summing up, the App needs:
OAuth API
Connection request API
User search API
I have read on the web that some of Linkedin's APIs suffered some modifications in which most of them where limited to allowed users or apps. So the aim of this post is knowing:
Do the APIs my mobile application needs exist?
What do I need to do to obtain the access to those APIs in case they exist?
User search API
For this feature you could use something like Algolia Instant Search
LinkedIn has changed many things related to user data. If you need access to its data then you must follow the given guidelines.
Basically you have to create a LinkedIn App and then the users have to grant permissions to your app by installing it in their device(s) and then only you can collect their data.
I am working on a web application which is based on Google App Engine (GAE). The requirement of the application is that one user can be associated with multiple company accounts.
My application has two main types of accounts. One is that main Admin/Company account. Other is the employee account (i.e. the persons who work under a company). Now, what I want to do is that to allow an employee to work under more than one companies, but he does not have to make a separate account for each company. His single account can be associated with multiple companies.
I have explored different platforms which are already supporting this feature. The major ones which I found are Slack and Asana. And my problem can be perfectly mapped to what Slack is doing right now i.e. I create a single account on Slack and I can join multiple workspaces on Slack using this single account.
I want to achieve the same in my application too. I am curious that how Slack is supporting this feature right now? Does it send some ID with every request to the server which indicates that the activity which just has been done is associated with the workspace under this ID? Or there is some unique sort of token associated with every workspace (on Slack API level)?
I do have such a model in my app. A unique auth_token is associated with every company account. So, I am thinking that when an employee wants to do an activity for a specific company he will send this unique token with the request to the server so that server knows for which company the activity was performed.
Does anybody know what is the best way of achieving this?
There are two different concepts at work here:
Relation between account and company / workspace
The data structure for the Slack account is designed such that it can be linked to multiple Slack workspaces, e.g. in SQL you would have a many-2-many relation between the accounts and the workspaces table.
Staying logged in
The way Slack and others Single-Sign-On provides like Google SSO keep you logged in is by settings a browser cookie. That cookie would usually be some kind of crypto hash and the SSO provider will use it to identify to which account the current user belongs to or to request a login via OAuth if the cookie is missing / invalid.
This can also be achieved partly with server sessions (which also uses cookies). Using server sessions is easier to implement than implementing your own (secure) cookie solution, however the user will only stay logged in as long as the browser stays open. But that should be sufficient for most solutions.
Note that tokens for the Slack API work very differently. e.g. they have to be generated per workspace, user and app.
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 want to build a dashboard to my clients access your respective website analytics. But, after some research, I'm stuck.
Let's imagine the scenario:
My Analytics Account:
Client X - websitex.com
Client Y - websitey.com
In my dashboard, when the cliente Y log in, the data (pageviews) of websitey.com is shown on graphics.
But, there's a way to do that? By the moment, the only thing i got is retrieve information for my logged account (my analytics ID), not the information about another account.
There's a way to use the Google API, or, I'll have a "separate database" to save data each website?
Sorry, I'm really lost at the moment.
You can only view Google Analytics Accounts that you are authorized to view. For some reason this is a source of major confusion (seeing that your are not the first to ask), although it should be fairly self-evident.
If you want to see data from your clients account you have to ask your client to add your Google email to the GA account. If an email address is added to multiple accounts you can, via the API, choose between the accounts. Clientside authorization (OAuth2) will only work as long as somebody is logged in via a client application (usually a browser). The practial effect is that everybody who is authenticated via OAuth against Google will see only his own GA accounts, not other peoples data.
If you want a serverside application to pull data from various GA accounts you need a service account. But even the service account needs to be added to the GA accounts.
You can use the core reporting API, but the API will not give you access to accounts that you are not authorized to look at; your client needs to authorize you (or your applications service account).
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)