I have a problem of sending SMS via API within one account where we have a bunch of numbers with their own extensions.
The goal is to be able to use any of these numbers for sending SMS from Salesforce via callout.
I've created an app with "SMS", "Read Account" permissions.
When I try to send a request from Postman using "Account" credentials with or without extension number, I receive an error: "Phone number doesn't belong to extension"
I cannot log in with default account credentials and different extensions.
I do not have other users credentials.
I cannot add number to extension as it already have own extension.
Is there any way I can solve this? Please, advice.
For now, you need to use an access token authorized by a user (extension) that has privileges to send/receive SMS on the numbers desired.
Given the scenario you describe, you will need to add a degree of indirection between the user taking the action and the user extension to which the number is associated.
To do this, you will need to build an app that manages access tokens for the extensions to which the numbers are assigned. Then your user will need to separately log into the app and select the number, at which time the app will use it's separately managed access token.
The authorization for user extensions associated with the numbers may be able to be authorized using OAuth 2.0 Authorization grant flow or, if your app is a private app the OAuth 2.0 Resource Owner Password Credentials grant flow.
Related
I'm sure I am missing something here but...
I have an angular application that allows users to fill out forms. The application calls a backend NODEJS service that has a responsibility of building the HTML envelope and document to sign. This back-end service does not have access to a browser.
I have 2 options for flow:
User fills out form -> clicks sign button -> back-end service called to gather the url for the user to redirect to in order to get a code back (consent) -> USER DOES NOT LOGIN TO DOCUSIGN -> redirect back to application -> get token with users code -> prepare envelope on BEHALF of the user -> send application the ceremony URL -> user redirects to ceremony -> signs document -> redirect back to application.
*User fills out form -> clicks sign button -> back-end service called to create envelope and tell DOCUSIGN to send an EMAIL to the user which I don't want to sign up for DOCUSIGN. (Effectively removing the need for them to create an account with DOCUSIGN because I am sending an email and they can authenticate him by knowing he is coming from his own email). -> user signs document through email -> (Would be nice for application to get redirected back to but not necessary)
All examples and chats I have seen discuss only having to login one time. Well in flow 1, I don't want the USER, signing the document, to login or have to make an account for this one signing. And in flow 2, I can't seem to grasp how to keep the back-end service authenticated if it is a BACK-END service. It's headless. No Browser.
These guys are so large that I figure it's something I'm not grasping here.
I understand to impersonate the user, I would need his consent. And possibly... because they don't KNOW the user without him signing up for an account to verify his email, they can't offer consent to a user they can't verify email with. So if that is the case, I would want to authenticate my BACK-END user to send emails so they can just click the email, it MIGHT verify in DOCUSIGN without having to sign up for account, and offer the contract to the user to sign on the spot from the email WITHOUT asking for credentials or NEW account.
If you are going to answer this with a link back to DOCUSIGN authentication examples. Or suggest use a JWT to authenticate from BACK-END services... please explain in detail the steps to authenticate my BACK-END user and keep him authenticated without using a web-browser or how to use the users consent from a redirect from DOCUSIGN without the user having to EVER create an account.
I have tried sending the user to the redirect URL with success if they already have their credentials cached in browser or already have a DOCUSIGN user. The flow works fine there. I get the users code, exchange it for token, create envelope, redirect user to ceremony, redirect back to application after signing complete.
I have read a bunch of articles that all point back to DOCUSIGN help with authenticating 1 of 3 ways with a browser. I need no browser login, or a better understanding of how to avoid the user creating a DOCUSIGN account.
Thank you so much!
Signer, user that signs, does NOT need to have a DocuSign account. They do not need to log in to DocuSign in order to sign. They can sign via email or embedded in your app, but they do NOT need to have an account or log in.
Your app's back end needs an access token to make API calls. This doesn't change the headless nature or the fact that it's back end. A token is a long string that your app uses to authenticate. This authentication is tied to a user in DocuSign that has an account. That is NOT the user that signs, but the user that make the API call. You have to have a user that makes an API call.
You can get a token using JWT authentication and your back end can generate it using the Node.js SDK (npm package) without the need for UI or for anyone to log in.
I wanna answer my application's reviews with service account. But regarding to api documantation of google play console, for answering review's, i need to have my auth'key. :
GET https://www.googleapis.com/androidpublisher/v3/applications/your_package_name/reviews?
access_token=your_auth_token
But in my json file that i got from "create key" on my service account page, i have nothing like: "auth token". What should i do?
Note: I also have 1 more small question: I wanna list all of my applications for google play. I found some non-offical api's that can retrieve all app's for spesific developer. But for that i need to have people's developer name that i cannot retrieve from any api.
But in my json file that i got from "create key" on my service account page, i have nothing like: "auth token". What should i do?
Your auth token is not in the key file you downloaded it contains what you need to request an access token.
Assuming that you have created service account credentials on Google cloud console. What you have in that file is the credentials you need to create an access token.
Your application calls Google APIs on behalf of the service account, so users aren't directly involved. This scenario is sometimes called "two-legged OAuth," or "2LO." (The related term "three-legged OAuth" refers to scenarios in which your application calls Google APIs on behalf of end users, and in which user consent is sometimes required.)
Requesting an access token using a service account requires a number of steps Preparing to make an authorized API call I recommend you look for a client library in your chosen language coding it yourself is not for the feint at heart.
I wanna list all of my applications for google play.
In order to do that you will need to grant the service account access to your accounts data probably by sharing the data with it. Or you will need to use Oauth2 to authorize your application then you will have access to it.
I'm using the /beta endpoints for Microsoft Graph API, but I'm getting an Unauthorized error when trying to create chat messages on behalf of other users (or any user).
In v1.0 of the API, the Create chatMessage method is not Supported, but in Beta it is: https://learn.microsoft.com/en-us/graph/api/channel-post-message?view=graph-rest-beta&tabs=http, as "Teamwork.Migrate.All" permission, which my Application has in Azure.
It is strange, because the same App can create Teams, channels and add members, but not add channel messages.
Anyone know where to look next?
Edit: I got this back now: "You need to add user delegated permissions in your application to at least Group.ReadWrite.All in portal.azure.com and then consent as user or Grant admin consent in portal. And re-run On behalf of a User | Get User Access Token request to update access token."
However, it does not make sense in regards to what the Beta documentation says about the permission "Teamwork.Migrate.All", which my app has as an "Application Permission": "Allows the app to create chat and channel messages, without a signed in user. The app specifies which user appears as the sender, and can backdate the message to appear as if it was sent long ago. The messages can be sent to any chat or channel in the organization."
If I'm an app and I have that permission, what should I do with a User Access Token? I'm using the App Access Token.
For simply posting message to Teams Channel using Application Permission is not supported by Microsoft Graph
Alternatively you can setup Incoming Webhook which is connector in MsTeams's channel and after finish set up on Teams channel you will received URL which you could use Postman or any API consumer app to send request(your message) to Incoming Webhook which will be post in Teams Channel
Sample Result Image
NOTE: Incoming Webhook is not support for replying post
You need to add user delegated permissions in your application to at
least Group.ReadWrite.All in portal.azure.com and then consent as user
or Grant admin consent in portal. And re-run On behalf of a User | Get
User Access Token request to update access token.
It seems that you need to use a user token instead of an application token to create chat messages. The only difference between them is that the user token requires the user to log in. The application token allows the application to create chat messages on behalf of other users. Currently, you can only use user tokens.
As your prompt message says, you need to grant the Group.ReadWrite.All delegation permission to the application, and then grant the admin consent for the permission, and then you need to use the auth code flow to obtain the access token.
Update:
I think what you are doing is importing messages, not creating chat messages, it does require you to have the Teamwork.Migrate.All application permission.
Importing messages is special, it requires you to create team and create achannel in the migration state, you need to include the migration value in the teamCreationMode and channelCreationMode instance attributes in the POST request. See: here.
Currently Google Assitant includes an easy way to request non-identifiable information about the user and a detailed flow to authenticate the user on a third party service through OAuth2. What about if all I need is have the user authenticate on Google itself? I tried filling in the account linking flow using Google OAuth2 information, but that seems not to work. If that last thing is supposed to work fluently than that would be enough of an answer.
Context: Users already authenticate only with Google on a related webpage. All I need is to link this already authenticated account with the less-authenticated account on Google Assistant.
Update, 25 Oct 2018:
As of 13 September 2018, there is now a much simpler way to access the user's account if your project uses Google Sign-In. Google Sign-In for Assistant will give you an ID Token with information about the user, including their Google ID, with their permission. This permission can be granted just using voice and is fairly streamlined.
You can combine this with a web- or app-based Google Sign-In to get their permission to access OAuth scopes if you need to access Google's APIs.
Update, 25 Oct 2017:
As of around 4 Oct or 7 Oct, Google has updated their policy (again) to restore language restricting OAuth endpoints that are valid. The terms now include
When implementing account linking using OAuth, you must own your OAuth endpoint
and it appears (from the comments below) that they now check for the Google endpoints to prevent this method from working.
At this point, the only thing you can do is setup your own OAuth2 server.
Original Post:
Broadly speaking, the auth tasks you need to do are in four parts:
Configure your project (in the cloud console) so that the Calendar API is enabled and that the OAuth2 client is correctly configured.
Configure the Action for account linking in the action console.
Configure the Actions on Google Integration for your API.AI Agent to indicate that sign-in is required.
When API.AI calls your webhook to fulfill an Intent, it will include an auth token as part of the JSON. You can use this token to make calls to the Google APIs you need.
Configure Cloud Project
You need to configure your cloud project so that it has access to the Google APIs you need and setup the OAuth2 Client ID, Secret, and Redirect URI.
Go to https://console.cloud.google.com/apis/dashboard and make sure you have the project you're working with selected. Then make sure you have the APIs you need enabled.
Select the "Credentials" menu on the left. You should see something like this:
Select "Create credentials" and then "OAuth client ID"
Select that this is for a "Web application" (it is... kinda...)
Enter a name. In the screen shot below, I used "Action client" so I remember that this is actually for Actions on Google.
In the "Authorized Redirect URIs" section, you need to include a URI of the form https://oauth-redirect.googleusercontent.com/r/your-project-id replacing the "your-project-id" part with... your project ID in the Cloud Console. At this point, the screen should look something like this:
Click the "Create" button and you'll get a screen with your Client ID and Secret. You can get a copy of these now, but you can also get them later.
Click on "Ok" and you'll be taken back to the "Credentials" screen with the new Client ID added. You can click the pencil icon if you ever need to get the ID and Secret again (or reset the secret if it has been compromised).
Configure the Action Console
Once we have OAuth setup for the project, we need to tell Actions that this is what we'll be using to authenticate and authorize the user.
Go to https://console.actions.google.com/ and select the project you'll be working with.
In the Overview, make your way through any configuration necessary until you can get to Step 4, "Account Linking". This may require you to set names and icons - you can go back later if needed to correct these.
Select the Grant Type of "Authorization Code" and click Next.
In the Client Information section, enter the Client ID and Client Secret from when you created the credentials in the Cloud Console. (If you forget, go to the Cloud Console API Credentials section and click on the pencil.)
For the Authorization URL, enter https://accounts.google.com/o/oauth2/v2/auth
For the Token URL, enter https://www.googleapis.com/oauth2/v4/token
Click Next
You now configure your client for the scopes that you're requesting. Unlike most other places you enter scopes - you need to have one per line. Then click Next.
You need to enter testing instructions. Before you submit your Action, these instructions should contain a test account and password that the review team can use to evaluate it. But you can just put something there while you're testing and then hit the Save button.
Configure API.AI
Over in API.AI, you need to indicate that the user needs to sign-in to use the Action.
Go to https://console.api.ai/ and select the project you're working with.
Select "Integrations" and then "Actions on Google". Turn it on if you haven't already.
Click the "Sign in required for welcome intent" checkbox.
Handle things in your webhook
After all that setup, handling things in your webhook is fairly straightforward! You can get an OAuth Access Token in one of two ways:
If you're using the JavaScript library, calling app.getUser().authToken
If you're looking at the JSON body, it is in originalRequest.data.user.accessToken
You'll use this Access Token to make calls against Google's API endpoints using methods defined elsewhere.
You don't need a Refresh Token - the Assistant should hand you a valid Access Token unless the user has revoked access.
After contacting Google the current situation seems to be that you should set up your own OAuth2 server, and then on the login screen of your OAuth2 server you should start the Google OAuth2 flow.
you have to have your own endpoint with Google Oauth2 - it is correct that you can't use Google Oauth itself as a provider. To use the Google OAuth service, you can use a "sign in with Google" button in your own endpoint instead.
Source: Contacting Google Actions on Google Support
Kind of speechless right now... as this seems to be a huge oversight on Google's part.
I am able to make it work after a long time.
We have to enable the webhook first and we can see how to enable the webhook in the dialog flow fulfillment docs
If we are going to use Google Assistant, then we have to enable the Google Assistant Integration in the integrations first.
Then follow the steps mentioned below for the Account Linking in actions on google:-
Go to google cloud console -> APIsand Services -> Credentials -> OAuth 2.0 client IDs -> Web client -> Note the client ID, client secret from there
-> Download JSON - from json note down the project id, auth_uri, token_uri
-> Authorised Redirect URIs -> White list our app's URL -> in this URL fixed part is https://oauth-redirect.googleusercontent.com/r/ and append the project id in the URL
-> Save the changes
Actions on Google -> Account linking setup
1. Grant type = Authorisation code
2. Client info
1. Fill up client id,client secrtet, auth_uri, token_uri
2. Enter the auth uri as https://www.googleapis.com/auth and token_uri as https://www.googleapis.com/token
3. Save and run
4. It will show an error while running on the google assistant, but dont worry
5. Come back to the account linking section in the assistant settings and enter auth_uri as https://accounts.google.com/o/oauth2/auth
and token_uri as https://accounts.google.com/o/oauth2/token
6. Put the scopes as https://www.googleapis.com/auth/userinfo.profile and https://www.googleapis.com/auth/userinfo.email
and weare good to go.
7. Save the changes.
In the hosting server logs, we can see the access token value and through access token, we can get the details regarding the email address.
Append the access token to this link "https://www.googleapis.com/oauth2/v1/userinfo?access_token=" and we can get the required details in the resulting json page.
accessToken = req.get("originalRequest").get("data").get("user").get("accessToken")
r = requests.get(link)
print("Email Id= " + r.json()["email"])
print("Name= " + r.json()["name"])
You need to implement the Oauth protocol with whatever Google Assistant app you are developing. Let me be a bit more clear:
The user is on the assistant, you need to link him to any data
you have on your App side
The access to the data you have about
your user is protected by an access token
Google then needs to
ask you for this token to have access to this resource
When
google has the token it can send it to the app so it validates every
requests to get the resource.
This is why you need to implement your own oauth server (Honestly it is just two more endpoints in your application): the identity is checked on google's side, but the link between the user and the resource to access can only be known by you.
The process above is valid, you just need to specify your own token endpoint and your own auth endpoint.
Note that if you only want to check that the user is logged in into google and get his email, you just need to implement the streamlined identity flow that does not require the /auth endpoint (Automatically Sign Up Users with Streamlined Identity Flows)
That beeing said I implemented the flow but get the same error :
expected_inputs[0].possible_intents[0]: Transactions/Identity API must be enabled before using.
I've been reading lots of documentation about Google API access and OAuth flow using it but I don't seem to get it working in my mind, so I want to get some help first in order to have a clear idea about how it works then I can code it using the corresponding API.
What I want to achieve is feed a Java application running in a PC with specific Google user data, like localization through Google Latitude API. In order to get this, OAuth must be used, so I need getting the user consent, then access the user data from the application running in my computer, and I don't know how to manage this.
I've already registered my application with the Google APIs Console and enabled the Google Latitude module. I've also tried the Latitude console application here and it works properly (a browser tab opened asking for a Google user; I entered it and I got the location data), but I'm having problems when trying to adapt the program flow to my needs.
In my application, the 'remote' user is supposed to send a request (a custom JSON message) to the server asking for service enable/disable, like allowing the server to track his/her position through Latitude. Then, AFAIK, the server should send to the user a URL so the user can give the consent, but I don't know how to get this URL and how the server realizes about this consent and gets the token (automatically? Google tracks this authorization process?). Once my server gets the specific user token, then I should be ready to get service data for that user using the received token.
As I said before, I've tried according to different references, but as the documentation seems to be really scattered and much of it is already deprecated, I've been unable to get it working.
Judging from your description, the installed app OAuth2 flow seems to be the right one for you.
At some point, presumably when a user is installing your desktop app, you should fire up a browser - either embedded one in your app or the default browser - and sent them to this Google OAuth2 endpoint. In your request, fill out all the parameters as required by the doc: Latitude API scope, client_id, etc. Google, as an authorization server, will take care of user authentication, session selection, and user consent. If the user grants access to her data to your API, you will receive an authorization code either in the title of the browser window or at a localhost port.
Once you have the code, you can exchange it for an access token and a refresh token. The access token is what you need to call the API and access the user's data. It is short lived though - check the expired_in parameter in the response, I believe it is 3600 sec. - so you will need to periodically ping the token endpoint with your long lived refresh token and exchange it for an access token.
You can find a more thoroough description of this flow in the doc linked above.