I'm having problems with Get New Access Token for Postman and SmartSheet.
All URLS are prefixed with https:// but StackOverflow would not allow that.
Callback URL: www.getpostman.com/oauth2/callback]
Token Name: Test
Auth URL: app.smartsheet.com
Access Token URL: app.smartsheet.com/token
Client ID: used the one provided when registering my app with SmartSheet
Client Secret: used the one provided when registering my app with SmartSheet
Scope: blank
Grant Type: [Authorization Code]
When I click Request Token it takes me to the SmartSheet Login. After I login and close the SmartSheet browser I get Could not complete OAuth 2.0 Login.
Looking at your example the Auth URL is incorrect. That should be
https://app.smartsheet.com/b/authorize
Also, the Access Token URL should be
https://api.smartsheet.com/2.0/token
The Smartsheet OAuth2 flow also requires a Scope, so it can't be left blank in spite of what Postman says.
More information on all of this can be found in the documentation:
http://smartsheet-platform.github.io/api-docs/#oauth-flow
It is important to note that with all of this set correctly setting this up in Postman still won't work. This is due to the fact that the Smartsheet process of obtaining and refreshing the token Smartsheet requires clients to hash the authorization code (with a pipe and the app secret, using SHA256) rather than sending it in clear text. This is arguably non-standard, but is still within the OAuth2 spec. More information on this process is at the documentation I referenced above.
Unfortunately, it does not look like Postman supports these types of deviations from "vanilla" OAuth2. Depending on what you are trying to accomplish, you will either have to go though the steps of the process manually, or stand up a third-party app in a hosting environment. If you are simply looking to generate a token, this approach http://smartsheet-platform.github.io/api-docs/#direct-api-access may work for you instead.
If you are trying to test in Postman the Direct API approach works. http://smartsheet-platform.github.io/api-docs/#direct-api-access
Step 1) Go to your actual smartsheet "https":"//app.smartsheet.com/b/home" and under Account>Personal Settings>API Access -- Generate a token (copy it you wont be able to copy after you close)
Step 2) Get the url for your sheet. Right click on the sheet name tab and select Properties. Copy the the Sheet ID (ie 123456). Add it to the end of the url: "https":"//api.smartsheet.com/2.0/sheets/123456"
Step 3)The most confusing one in my opinion. In Postman select No Authorization. Then go and update the header with "Bearer 0da6cf0d848266b4cd32a6151b1". You have to have the word Bearer and the randomly generated string of numbers is from Step 1.
Then send the get request and you get your sheet back in json format.
Related
On my site, I want to be able to retrieve whether my own YouTube account goes live. After looking around, I found this endpoint:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts,
that would help me do just that. However, the main problem I found is that it requires an OAuth2 token, and the only way I could find to generate one was going through the whole Login with Google approach.
My main problem is that I want anyone who visits my site, to be able to see whether I'm live or not. I'm not looking for workarounds or using web crawlers either - I want to be able to use this specific endpoint. Is that even possible?
In other words, is it possible to get my own access token manually, and just plug that into the API request to access the endpoint directly? Or is this just impossible?
First thing to know about YouTube Data API is the following: for to issue authorized request to it, one cannot alleviate authentication through the browser.
You may read the doc OAuth 2.0 Flow: Installed apps for thorough info about the authorization flow on standalone computers.
The doc specifies step 4 -- Handle response from Google -- and step 5 -- Exchange authorization code for refresh and access tokens. By the initial OAuth flow, you get two tokens: a short-lived access token and a refresh token that produces access tokens on demand. Authentication without browser is not possible, but once having a refresh token, it can be traded programmatically for access tokens:
Initialization: obtain via browser authentication a refresh token;
Iterations: as many times as needed, query the API for an access token -- without any browser interaction! -- using the refresh token from (1), then proceed further with the call to the target API endpoint (again, without any browser interaction).
Note that the steps (1) and (2) may well be separated such that (1) is executed by a standalone (local) computer that stores the refresh token into a file; later, upon a secure transfer of that file on a different remote computer (e.g. a server that does not have a browser installed), execute (2) on that remote computer, repeatedly as needed
(see Using OAuth 2.0 for server-side, standalone scripts.)
Sounds right:
complete the flow (once) with your own google account,
cache the token server-side, and
include the API’s response when serving your page.
Pitfalls:
How long are OAuth tokens valid for? (The API will start returning errors if this occurs)
How often will the page be generated vs. what rate-limits does the API have? ( you may have to request status at most once per few minutes, and cache the response)
so I am trying to request an authorization code from smartsheet using postman.
I created a new app on my smartsheet with the following url:
app url: https://localhost:3000/
redirect url: https://localhost:3000/callback
so I tried to use the
GET https://app.smartsheet.com/b/authorize
and input my client id, scope, repsonse_type, and state in postman
the result says there is an error and it did not direct me to a page where I am able to allow authorization.
I am expecting something similar to what the website says (http://smartsheet-platform.github.io/api-docs/#access-levels). I am not sure which part I did was wrong, I am wrong home for this volunteer work hence I do not have an appropriate url. I don't know if it's my urls that are causing the problem or there's something else.
thank you guys in advance
If you are building out the Smartsheet OAuth flow you will need to have a hosted environment where you can have requests sent and be able to open a page in a browser to authenticate to the Smartsheet account and select the Allow button to confirm the access token should be created and returned to your application.
For development purposes you can use a service like ngrok to create a publicly available URL for your localhost which will allow you to send and receive the necessary data from Smartsheet in your development environment.
Authorization tokens cannot be generated from the API - you must do them from the website. From the API documentation:
Click the "Account" button in the upper-right corner of the Smartsheet screen, and then click "Personal Settings".
Click the "API Access" tab.
Click the "Generate new access token" button to obtain an access token.
When I try to make the following call using postman I get no response: https://slack.com/oauth/authorize?client_id={{client id}}&scope=chat:write:bot
However, when I try it without the scope I do get a response, saying I need to add a scope.
I've put this call together according to the first step of https://api.slack.com/docs/oauth
I've tried using both GET and POST verbs and my header is empty.
What can I do to get a authorization token for Slack?
This is part of the OAuth flow/spec.
What you need to do to is follow/perform the OAuth flow:
Register your application with slack
Provide a redirect_uri - this is the callback URI - this callback/handler will be called with the authenticationCode by the slack OAuth server.
Only if the user authorizes your app, Slack will redirect back to your specified redirect_uri with a temporary code in a code GET parameter, as well as a state parameter if you provided one in the previous step.
It's true that the redirect url is optional, but if left out, Slack will redirect users to the callback URL configured in your app's settings.
the authenticationCode then needs to be changed in code to the accessToken.
So if all is well and user gave its consent, you need to exchange the authorization code for an access token using the OAuth.access API method (method documentation), int the following URL and retrieve your accessToken.
https://slack.com/api/oauth.access
if you decide to use a bot user and your Slack app includes a bot user, you will get an additional node containing an access token to be specifically used for your bot user.
How can I setup PAW to work with Facebook locally for development? Or even at all for that matter?
I have a node.js backend that I'm setting up with Facebook Auth. Every one of my routes needs the user to be logged in. I have two endpoints related to FB Auth. localhost:3000/api/v1/loginFB and localhost:3000/api/v1/callbackFB. Both of these work great in a web browser.
loginFB simply returns this string... https://www.facebook.com/dialog/oauth?client_id=523534457345&redirect_uri=https://localhost:3000/api/v1/callbackFB&scope=email,public_profile,user_friends.
When I call that URI in a browser, it returns a code=blahblah which my callbackFB endpoint uses to fire off another request to get the access token. All good.
So now in PAW I'm confused by the difference between the request URI and the Authorization URL text field? Should I use the loginFB URI for my request URI? And then https://www.facebook.com/dialog/oauth in the Authorization URL textfield?
Basically what's happening is that when I click Get Access Token, it returns the code but my callbackFB endpoint 500's by saying "This authorization code has been used." The code that it's getting returned is definitely different each time I Get Access Token.
This is where I'm at with this thing (Client ID and Client Secret are actually my App ID and App Secret from fb's dev management site, and the Access Token URL is actually set to https://graph.facebook.com/v2.3/oauth/access_token which I'm 99% sure is the correct URI):
This is the error I get when I click Get Access Token button:
It would be awesome to get some advice from anyone with experience with this issue. Thanks.
Re: #MichaMazaheri
tl;dr Fixed in version 2.2.2
Sorry for the super late follow-up. We actually fix this exact issue in Paw 2.2.2, which is already released on our website, and pending review for the Mac App Store. (It was some JSON vs. Form URL-Encoded parsing issue). Thanks for reporting.
As a proof of concept for a simple background application, I used the Graph API Explorer to create an access token for my app to post something to the wall of a page I maintain. It worked fine. Naturally, however, the token expires.
So now I'm trying to have the background application automatically request a new page access token each time it runs. And I'm having a lot of trouble finding a concrete definition of how to do that. There's no shortage of information regarding Facebook and Access Tokens, but nothing seems to demonstrate how to have a background application post to a page. (Not post to a user's wall, not display a login dialog to a user since it's a background application, etc.)
I can fetch an access token in code easily enough by reading the response from a web request to this URL:
https://graph.facebook.com/oauth/access_token?grant_type=client_credentials&client_id={MY_APP_ID}&client_secret={MY_APP_SECRET}
Of course, that "access token" doesn't work when trying to post to the page's wall. It says that the user hasn't authorized the application to perform this action. The action I'm performing is pretty simple:
var client = new FacebookClient(GetFacebookAccessToken());
dynamic parameters = new ExpandoObject();
parameters.message = "this is a test";
dynamic result = client.Post("{MY_PAGE_ID}/feed", parameters);
I've read in some places that I'll need to make a second request, using the first access token, to get the page access token. But I can't seem to find examples of how to do that.
Can someone shed some light on this for me?
I have a Facebook page.
I have a Facebook app which serves no other purpose than to provide a means for a local background application to access said page.
I just need that application to be able to authenticate so it can post something to the page.
(And if there's a step I need to perform in the Facebook UI to permanently give the application permission to do this, I think I've performed that step but it would be good to double check somehow.)
Edit: It's been described to me that I need to obtain a long-lived user access token and, using that, obtain a page access token. The theory is that said page access token won't expire. However, what's not clear to me is how one accomplishes this.
I've read the page describing the deprecation of offline_access, as well as the page describing server-side access. However, I'm clearly misunderstanding something. In the former, it references the latter for obtaining the proper token. The latter, however, includes steps for presenting a login to the user, having them accept permissions, and using the response from that login.
Being a background process that runs unattended, presenting any sort of question to a user (which would be me) isn't really an option. I've also been told that I can't do a one-time request from my browser to get an access token because that is, by definition, client-side interaction and not part of the necessary server-side flow. (It seems odd to me that the service would care if a RESTful request comes from a web browser vs. from an application, but I'm not familiar enough with OAuth or the Facebook API to really make that call.)
So, if I can perform some manual steps to get a permanent access token for the app to post to the Facebook page, what are those steps? Conversely, if I can perform some automated steps in the application to acquire access each time it runs, what are those steps?
(Making a few more API calls from the application adds a second or two of running time to an otherwise once-a-day process, so it makes no difference to me which approach to take.)
At first I just went into the Facebook Application settings and re-enabled the deprecated "offline access" permission. Said application settings can be found at a URL like this:
https://developers.facebook.com/apps/{APPLICATION_ID}/advanced
However, since everything keeps referring to that setting as being "deprecated" then I didn't want to use that as a long-term solution. It may get removed entirely, it may be unsafe in certain circumstances, etc. Better to use recommended functionality.
So here's what I was able to piece together from a scavenger hunt through updated documentation, outdated documentation, a sea of outdated internet posts, and PHP code which mostly made assumptions about functionality that aren't true in all cases...
Visit the Graph API Explorer and select your Facebook Application from the drop-down menu. Click "Get Access Token" and select the permissions you want. (For mine I went to the "Extended Permissions" tab and selected "Managed Pages" and "Publish Stream.") You will be prompted (in my browser it was in a new tab) with a familiar screen where the Facebook Application is asking you, the user, to grant it the permissions you just selected. (You've seen this before if you've ever agreed to use a Facebook Application before.)
The value it produces in the Graph API Explorer (a long string of random-ish characters) is your "Short Lived User Access Token."
As described here in "Scenario 4: Client-side OAuth and Extending Access_Token Expiration Time through New Endpoint" access this URL in your web browser:
https://graph.facebook.com/oauth/access_token?
client_id={APPLICATION_ID}
&client_secret={APPLICATION_SECRET}
&grant_type=fb_exchange_token
&fb_exchange_token={SHORT_LIVED_USER_ACCESS_TOKEN}
(You can obtain the {APPLICATION_SECRET} value on the basic settings page for your Facebook Application: https://developers.facebook.com/apps/{APPLICATION_ID}/summary)
This will return another Access Token as such:
access_token={LONG_LIVED_USER_ACCESS_TOKEN}&expires=5184000
This access_token value (another long string of random-ish characters) is your "Long Lived User Access Token." The expires value is in seconds, which translates into 60 days.
Now we hop over to the Page API reference and take a look at the section on Page Access Tokens. This, along with the basic structure of Graph API requests exemplified here (scroll down to the part where it shows a bulleted list of sample links which include access_token specifiers, which you'll need to specify here because you're requesting non-public information) leads you to request this in your browser:
https://graph.facebook.com/{FACEBOOK_USER_ID}/accounts?
access_token={LONG_LIVED_USER_ACCESS_TOKEN}
This will return a JavaScript object containing lots of useful information about the Facebook Pages and Facebook Applications your user account controls. In my case the Page and the Application had the same name, but it's easy to tell them apart from the category values or, if all else fails, the id values. Find the Page that the background application running on your machine will need to access and copy its access_token (the third and final long string of random-ish characters). The whole node looks something like this:
{
"name": "Some Facebook Application Name",
"access_token": "{LONG_LIVED_PAGE_ACCESS_TOKEN}",
"category": "Musician/band",
"id": "{APPLICATION_ID}",
"perms": [
"ADMINISTER",
"EDIT_PROFILE",
"CREATE_CONTENT",
"MODERATE_CONTENT",
"CREATE_ADS",
"BASIC_ADMIN"
]
}
This is your "Long Lived Page Access Token." This is the value you use to initialize the FacebookClient object in the code. Then, posting a simple status update is as easy as:
var client = new FacebookClient("{LONG_LIVED_PAGE_ACCESS_TOKEN}");
dynamic parameters = new ExpandoObject();
parameters.message = "This is a my status update.";
dynamic result = client.Post("{FACEBOOK_PAGE_ID}/feed", parameters);
Supposedly this "Long Lived Page Access Token" does not expire after 60 days like the "Long Lived User Access Token" does. I'll find out in 59 days, I guess.
NB: The curly braces in my examples are part of the placeholder for actual values. Do not use the curly braces in the actual requests. So something like this:
https://developers.facebook.com/apps/{APPLICATION_ID}/advanced
becomes something like this, for example:
https://developers.facebook.com/apps/123456/advanced
where 123456 is the actual Facebook Application ID.
Being a background process that runs unattended, presenting any sort of question to a user (which would be me) isn't really an option.
As I already said, you only have to do it once.
You get your non-expiring page access token, copy&paste that into your app – and from then on your app can do server-side whatever it wants to do happily everafter.
I've also been told that I can't do a one-time request from my browser to get an access token because that is, by definition, client-side interaction and not part of the necessary server-side flow.
The server-side auth flow for getting a user access token also needs to take part partly in the browser.
It does not matter, if you get a short-lived token via the client-side auth flow and extend it afterwards, or if you get a long-lived one using the server-side auth flow.
(It seems odd to me that the service would care if a RESTful request comes from a web browser vs. from an application […])
Facebook does not want users to give their login credentials to any third party. Therefor, the process of getting a user access token always has to take part in the browser, with the user login in to Facebook.
So, if I can perform some manual steps to get a permanent access token for the app to post to the Facebook page, what are those steps?
Get a long-lived user access token with manage_pages permission. (Or get a short-lived one, and extend it). And then, use that long-lived token to request a page access token for the target page, in the way that is described in the docs.