We are using basic instructions for account linking with a skill realized with google actions, dialogflow and external fullfillment.
We use systemIntent actions.intent.SIGN_IN to start the account linking process, which allows us to get user's email.
However, the default text used by google to require permission is very difficult to understand for users. It seems that the user is opening a new account, while he is only giving permission to pass the email to the skill.
Is there the possibility to modify such text?
No, there isn't. The text is specifically chosen by Google to be standard, consistent across Actions, and make it clear what permissions the user is granting to your Action.
Related
I am not able to test the Google Action. I'm getting an error:
The Web & App Activity permission is enabled, but the administrator of your Google account does not allow that. Please reach out to the administrator to change the preference.
But My team members are able to test it and we have the same privileges. I can't test it. I am not able to the "Account Linking" also.
In order to use Actions on Google or the Assistant, you will need your account's activity controls for "Web & App Activity" to be enabled.
You seem to be using a GSuite account, so this change may not be possible to toggle by yourself. In a work or school environment, the ability to change certain settings may be restricted by whoever manages the accounts. Depending on the scale you may be able to get the IT department to enable this setting.
Porting the project over to a standard GMail account will allow you to test the Action without this restriction.
I'm able to setup sugarcrm to my local machine. Also I've a bit of knowledge of studio. Now I've got a requirement like login to sugarcrm using google account. If user want to login to sugar he/she'll have to use his/her google credential. If the credential is correct and the email id matches with the email id for a user in user module, the he'll be able to login to sugar.
I'm pretty new to sugar so please provide help. Please write if the problem description is not clear to you.
Thanks
It sounds like your goal is to enable Google Authentication within SugarCRM, which would mean a rewrite of the entire login page and process. I think that's beyond the scope of a SO post, but I think you'd start here: https://code.google.com/p/google-authenticator/
SugarCRM does come equipped with the Zend Library, including a lot of classes for working with Google APIs, so that's a plus.
A simpler answer, if it meets requirements, is to set the Users' user_names to their google email addresses, either #gmail.com or #googleappdomain.com, whatever. The draw back here is that the accounts aren't actually linked with Google, so passwords won't stay in sync.
For my own gmail account, I have multiple email addresses associated with it. For example, I have an email address from my university that is associated with my gmail, and I can send emails from my gmail as if they are coming from my university email address.
I'm reading up on the Google APIs, and I see that I can get a user's gmail address, but can I also get any other email address that is associated with their gmail account?
When a user logs in to my site, I'd like to present them with a list of the gmail-associated email addresses and let them select the one they would like to use.
EDIT: Thanks everyone for the answers, but I don't think any of them answers the question. I've been playing with Google's OAuth playground. It is strange that I can get lots of very personal information (a list of a user's contacts and even received emails) but I can't get the user's alternative email addresses.
Your description is a little vague. Are you talking about send-as alias accounts or alternate email accounts?
Send-as Alias
Either way, you can interact with the send-as accounts here: Manage Send-as Alias
Alternate Emails via Admin SDK
As for alternate email accounts, they can be accessed via:
Admin SDK: https://developers.google.com/admin-sdk/directory/v1/guides/manage-user-aliases?hl=en
Google Apps Script: https://developers.google.com/apps-script/reference/gmail/gmail-app#getAliases()
Additional info here on how the accounts work.
Email addresses associated with your account
Alternate email addresses and other Google products
Connect other email accounts to your Google Account
Federated Login
Also, I'm not exactly sure how you are trying to incorporate this functionality into your site but another area I recommend checking out is Federated Login for Google Account Users. This might also provide you with the functionality you seek.
Using federated login (also known as federated identity), your website
or application can allow visitors to sign in using their Google user
accounts. Federated login frees users from having to set up separate
login accounts for different websites, and frees you from the task of
implementing login authentication measures.
It has been a while since the question was asked. You can use the Google People API to get a user's primary email address and aliases. Here's the documentation. The scope you need to use is: https://www.googleapis.com/auth/user.addresses.read
This will return all the email addresses for the user and also tell you which is the primary one.
If you use OAuth to have your users sign-in with their Google accounts (with or without G+) the user will be prompted (by Google) to select which of their accounts they wish to authorize your application to use:
https://developers.google.com/accounts/docs/OAuth2Login
So to directly answer your question, I'm not aware of an API to return that list of users - however you shouldn't need to, Google will take care of this before returning to your application.
If your user is already logged in, and you wish to give them the ability to change the Google account they are using, I believe it is possible to prompt them again to select the account they are interested in (search for select_account on the link above).
This is possible. However, this has changed since Google announced the deprecation of their Google+ People API, which a lot of folks used to get all the email addresses for a user. The current most voted answer now goes to a 404.
Google Plus People API Replacement
Google has replaced the Google Plus People API /plus/v1/people/me with https://developers.google.com/people/ and you’ll want to use the https://www.googleapis.com/auth/user.emails.read profile scope as discussed here as a replacement. The schema is different, so you'll need to change your mapping as well.
If your app already used the following scopes from the old /plus/v1/people/me your user will not have to re-consent when you switch to the new API:
email
profile
https://www.googleapis.com/auth/plus.login
https://www.googleapis.com/auth/plus.me
https://www.googleapis.com/auth/plus.profile.agerange.read
https://www.googleapis.com/auth/plus.profile.emails.read
https://www.googleapis.com/auth/plus.profile.language.read
So there are definitely many tutorials out there regarding how to integrate various individual social network authentication/registration into existing user accounts. But the scenario I can't seem to find out much information about is if a user signs into your account with different social network credentials. For example:
Scenario #1
User registers on site using site's authentication.
User then signs in/registers on site using Facebook Connect.
User then signs in/registers on site using Twitter.
How do I integrate all of these into one account?
Obviously once a user is registered, they can add other social network associations in the account settings pages. But I am more concerned if they register via the other social network not remembering they are already setup.
My general thoughts are trying to figure out a way to use the "username" or email to try and guess and present the user a way to combine accounts right there.
Anyone have any thoughts?
following up -
if your users can't remember that they've signed up previously, well, best of luck to them in general ;)
much as you described, i'm planning on giving users the option to link additional accounts once they have signed in by one means or another.
but as far as cross-checking, there's only so much you can do. many social network APIs do indeed provide email addresses (once you've busted in through OAuth) but these may be accessible only if a user has elected to make his/her address public, which is not guaranteed.
also not guaranteed is that the user used the SAME email address for each social network account, so even if you manage to retrieve an address it may or not be of any use to you.
finally, if you find matching email addresses via such means, it might be advisable to prompt the user to link accounts rather than assume he/she wants this done automatically. some people like to maintain multiple personalities. i.e. "it looks like you are also signed up with twitter - do you want to link your accounts? it will make your life seem worth living."
you might consider offering incentives to link user accounts or to provide an email address (up to you of course to figure out what these might be, based on the functionality of your website).
solution i am working on, database-side, is to maintain multiple accounts and then if link information is discovered by various means, said link is indicated in a lookup table.
an alternative is once you find a link, attempt to combine all relevant entries for the multiple accounts into one account entity - all i can say about this latter approach is that i would do so with caution as there could be a formidable level of complexity depending on the user's activity level and the complexity of your database schema.
in my (mental/actual) namespace a user who registers the old-fashioned way has a 'standard' account and one who uses a social network has an 'alias' account. then the goal becomes to define where the alias is supposed to point, i.e. create the lookup such that a subsequent login via either means retrieves the relevant information for both accounts (with a preference for displaying personal data for the 'standard' account).
btw i figured out how to make twitter OAuth behave since my last post - you can look at my other answers for details if you're interested.
JB
hi matt,
i'm working on the same problem right
now.
assuming the user starts with regular
site account (which is not
necessarily safe to assume if he sees
all the pretty "connect with XXX
network" buttons!!!), you can use
either OAuth or the javascript APIs
(facebookConnect or #anywhere -
haven't fully figured out the latter
yet and i'm not sure I recommend it as
I don't think it provides as rich an
API as do the backend libraries) to
login to the other sites.
the APIs should return certain
information after a successful
login/redirect from the social network
- such as the user ID and an ACCESS TOKEN which you can then store in your
database in some capacity associating
your 'actual' application user with
the ID of the social network.
when the user returns to the site, you
can then
1 verify cookies set by the social
network services (various schemes
typically verifying a signature, based
on sha1 or md5 hash of your
application data - by which i mean the
data you get when you register your
app with twitter/facebook, typically a
consumer key, application ID, etc. -
with the received cookies) so you know
the user has logged in with the social
network
2 find your database entry association
as described above
3 login your user manually based on
the assumption that facebook/twitter
connection is secure.
caveat: this is only as secure as your
implementation (or as secure as
facebook/twitter's implementations, if
you prefer...)
although twitter's OAuth does not
currently seem to work quite right,
their general description of the
process is pretty informative:
http://dev.twitter.com/pages/auth
good luck.
J
I have been contemplating adding FB auth to our app, but we know that our returning users might click it and complete checkout for a new item, and then be surprised to not see any of their existing orders. To solve this, when a user clicks the 'Login with Facebook' item, we are using that click to fire a dropdown menu with two options:
[ Login with Facebook ]
[ Create new account ]
[ I have an account ]
If the user clicks 'I have an account' we send them to FB auth and return email from FB to our app. We compare that email to our existing users. If we match, we add the FB creds to the user. If no match, we throw an alert:
The email you have with FB does not match any of our accounts. To log in to your existing account, login with your email below, or update the email in your Facebook account
This allows the user to create a whole new account, if they want to keep them separate, without needing a new email service. While this is an edge case, it is a feature.
I hope this is allowed but I have a number of questions regarding Facebook Connect, I'm quite unsure on how I should approach implementing it.
I am working on a live music type service and currently have user registration, etc. If I were to implement Facebook Connect alongside this, would I still be able to email the Facebook Connect users as if they were on my database?
Also, would it instead be possible to let users who have Facebook "link" their accounts once registered so I am able to give them the benefits of sharing via Facebook and inviting friends while still having an actual registered user on my system.
I have tried to read up answers to the above questions but what I've found is quite ambiguous.
Thanks, look forward to your views.
Facebook's documentation process is very poor, so don't feel bad about having a hard time getting started. Their wiki-style approach to documentation without any real official documents tends to leave the "process flow" tough to grasp, and requires piecing together parts of a bunch of randomly scattered docs.
Facebook has an obligation to protect privacy, so they never make a user's actual email address available to application developers, through Connect or normal applications. They do have a proxied email system in place that you can use, however, you must get explicit permission from a user in order to email them. There's a decent document on proxied email here. You can get permission by prompting for it; there's several methods for doing so linked in that document.
In regards to linking Facebook and local accounts, this would definitely be the way to go. Once a Connect user logs in, you want to store that fact for that user so you can provide the Facebook-specific functionality. I would simply create a normal user account in the database for every new Connect user that came by, with it's own local id, so that you don't have to do special handling of two different types of user accounts all over the site. That being said, the account would obviously have to be marked as a Facebook user's account (I use an externalId column in my users table), and any part of the site that relied on information you might otherwise have locally would have to handle the Facebook aspect properly (such as using proxied email instead of normal email).
For existing users, you could arrange an "account link" by having a process whereby they log into FB Connect after they've logged into the site already, and you could detect that and simply add their FB id to your users table. After that, they could log in through Connect in the future, or through your normal process. I've never done this, but it should be possible.
If you write the account handling code generically enough, your site will be able to function well no matter what kind of user you throw at it.