I am attempting to use postman with imgur api I used the 'open with postman' button at the top of the documentation page and tried to obtain a token with the default populated settings for callback authorization and token url's and I get a popup window with:
{"data":{"error":"redirect_uri_mismatch","request":"/oauth2/authorize","method":"GET"},"success":false,"status":400}
I am hoping this is a simple thing as i am pretty new to api's.
`Further info:
callback url: https://www.getpostman.com/oauth2/callback,
auth url: https://api.imgur.com/oauth2/authorize,
Access Token url: https://api.imgur.com/oauth2/token,
no Scope,
no State ,
Client authentication: send as basic header
`
I've got the same problem but I fixed it.
See if your callback URL in Postman is the same as your Redirect in Imgur (You can always edit it in Imgur) https://imgur.com/account/settings/apps.
Also, make sure that there is no comma at the end in the callback URL in Postman (That was my mistake). Everything else looks fine but just in case I'll show you what I have.
Postman:
Get -> https://api.imgur.com/3/account/me/images
Callback URL: https://www.getpostman.com/oauth2/callback
Auth URL: https://api.imgur.com/oauth2/authorize
Access Token URL: https://api.imgur.com/oauth2/token
Scope, State: Empty
Client Authentication: Send as Basic Auth header
Related
I am trying to get new access tokens before they expire using reconnect api endpoint, but the api call to https://appcenter.intuit.com/api/v1/Connection/Reconnect is being redirected to https://quickbooks.intuit.com/learn-support/en-us/do-more-with-quickbooks/third-party-app-security-requirements-updating-soon/01/428295, rather the expected response. Am i missing something here? Appreciate the help.
According to Intuit's documentation, you're using the wrong URL:
https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#refresh-the-token
Did you try using the correct URL?
From the docs:
To refresh an access token, your application sends an HTTPS POST request to
Intuit’s authorization server
(https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer)
that includes the following parameters:
I am trying to use the MongoDB Stitch examples tutorial for the Web based Todo App. I am using Node.JS v10.14.2 on a Ubuntu 18.04 Bionic Beaver Linux station.
When I try to log in with Facebook, the login process fails with Facebook complaining that the redirect URL generated by the Stitch server is not whitelisted, and therefore has been rejected during the attempt to login into Facebook with OAuth. The URL is generated during this code block found in this Node module:
node_modules/mongodb-stitch-browser-core/dist/cjs/core/auth/internal/StitchAuthImpl.js
Here is the code that generates the URL that starts the login process. It calls the Stitch server and the Stitch server generates the correct URL to ask Facebook to login the user. Note, I did modify the code but only to show me the value the getAuthProviderRedirectRoute() call was generating. No other changes were made.
StitchAuthImpl.prototype.loginWithRedirect = function (credential) {
var _this = this;
var _a = this.prepareRedirect(credential), redirectUrl = _a.redirectUrl, state = _a.state;
this.requestClient.getBaseURL().then(function (baseUrl) {
// ROS: We want to see the URL being created - ESM.
let replaceUrl = baseUrl +
_this.browserAuthRoutes.getAuthProviderRedirectRoute(credential, redirectUrl, state, _this.deviceInfo);
_this.jsdomWindow.location.replace(replaceUrl);
});
};
Here is the value of replaceUrl that shows the URL that was generated at this initial stage of the Facebook login process:
replaceUrl = https://stitch.mongodb.com/api/client/v2.0/app/my_stitch_app/auth/providers/oauth2-facebook/login?redirect=http://localhost:8001/&state=<<redacted>>&device=<<redacted>>
Stitch generates this URL for the start of the OAuth Facebook login handshake. As you can see from the code this URL is loaded into the browser's location. The stitch server then generates the URL for the next leg of the OAuth handshake. I have excerpted the redirect_uri query argument from the URL it generates and transfers control to, shown here:
redirect_uri%3Dhttps%253A%252F%252Fstitch.mongodb.com%252Fapi%252Fclient%252Fv2.0%252Fauth%252Fcallback
I then manually decoded the redirect URI because it looked wrong. If you look at the redirect_uri query argument shown above, you will see that the OAuth callback URI has been double encoded with the encodeUri() method. This causes the Facebook OAuth server to reject the callback URI because after being decoded, it looks like the URL shown next to the DECODED ONCE label shown below.
This causes the OAuth handshake to fail because it does not match the URL that you see below marked with the label "DECODED AGAIN".
That value is what I put in the Facebook OAuth "Client OAuth Settings" page in the "Valid OAuth Redirect URIs" section as instructed to by the MongoDB Stitch tutorial. Since the URL has been double encoded, the redirect URI when decoded once, doesn't match the "DECODED AGAIN" value and the login process fails. Obviously I could add the "DECODED ONCE" value to the whitelisted URLs list, but that would just kick the problem down the road because it should look like the completely decoded value in "DECODED AGAIN".
DECODED ONCE:
redirect_uri=https%3A%2F%2Fstitch.mongodb.com%2Fapi%2Fclient%2Fv2.0%2Fauth%2Fcallback
DECODED AGAIN:
redirect_uri=https://stitch.mongodb.com/api/client/v2.0/auth/callback
To recapitulate, when Facebook is asked to login in the user with the URL generated by Stitch, shown below, Facebook fails the process with the error message also shown below:
https://www.facebook.com/login.php?skip_api_login=1&api_key=<<redacted>>&kid_directed_site=0&app_id=<<redacted>>%26redirect_uri%3Dhttps%253A%252F%252Fstitch.mongodb.com%252Fapi%252Fclient%252Fv2.0%252Fauth%252Fcallback
Facebook Error:
URL Blocked
This redirect failed because the redirect URI is not whitelisted in the app’s Client OAuth Settings. Make sure Client and Web OAuth Login are on and add all your app domains as Valid OAuth Redirect URIs.
I have scoured the MongoDB Stitch control panel and I don't see anywhere I may have entered something that would lead to the callback URL being passed to Facebook by Stitch, to be double-encoded. Can anyone tell me what could cause this unwanted behavior and how to fix this?
Thanks for the detailed explanation. I tried reproducing your issue but I was able to login with Facebook successfully.
I also checked the URL that the Stitch server generates when redirecting to Facebook, and it was the exact same double-encoded URI you have in your post. This means that this behavior is expected and should not affect the login flow.
If you look at the full URL, you'll see that the main url (starting at "https://www.facebook.com/login.php") has a query parameter called "next". The "next" parameter is a URL, so it needs to be URL-encoded. This URL passed to "next" has the "redirect_uri" parameter, which is also a URL, so it needs to be URL-encoded as well. Since this is a URL in a URL in a URL, this is why you see the double-encoding.
I formatted the URL with each parameter on a new line, and each sub-URL intended to help demonstrate this:
https://www.facebook.com/login.php
?skip_api_login=1
&api_key=<redacted>
&kid_directed_site=0
&app_id=<redacted>
&signed_next=1
&next=https%3A%2F%2Fwww.facebook.com%2Fdialog%2Foauth
%3Faccess_type%3Doffline
%26client_id%<redacted>
// this is the double encoded URL
%26redirect_uri%3Dhttps%253A%252F%252Fstitch.mongodb.com%252Fapi%252Fclient%252Fv2.0%252Fauth%252Fcallback
%26response_type%3Dcode
%26scope%3Demail%2Bpublic_profile
%26state%3D<redacted>
%26ret%3Dlogin
%26fallback_redirect_uri%<redacted>
&cancel_url=https%3A%2F%2Fstitch.mongodb.com%2Fapi%2Fclient%2Fv2.0%2Fauth%2Fcallback
%3Ferror%3Daccess_denied
%26error_code%3D200
%26error_description%3DPermissions%2Berror
%26error_reason%3Duser_denied
%26state%3D<redacted>
&display=page&locale=en_US
To get Facebook login working, I would ensure the following:
In the Facebook console, make sure this URL is added to the list of "Valid OAuth Redirect URIs":
https://stitch.mongodb.com/api/client/v2.0/auth/callback
In the Stitch console, make sure that your application URL is included in the list of "Redirect URIs" for the Facebook Provider. This should include any trailing slashes.
In your application code, make sure you are calling the following JS code when your redirect URL is hit. This allows the the Stitch client SDK to get the result of the OAuth2 flow performed by the Stitch server:
if (yourStitchClient.auth.hasRedirectResult()) {
return yourStitchClient.auth.handleRedirectResult().then(user => {
console.log("Authenticated as user: " + user);
});
}
Check out https://docs.mongodb.com/stitch/authentication/facebook/ for more explanation on these steps.
If you're still having trouble getting this to work after the above steps, let me know and I'll try to help you debug the issue.
I want to send a request to this Amazon Alexa API.
That page contains the last 50 activities I made with my Amazon Echo. The page returns JSON. Before you can request that page, you need to authorize your account, so the proper cookies are set in your browser.
If I do something simple as:
const rp = require("request-promise");
const options = {
method: "GET",
uri: "https://alexa.amazon.com/api/activities?startTime=&size=50&offset=-1",
json: true
};
rp(options).then(function(data) {
console.log(data);
}).catch(function(err) {
console.log(err);
});
I can send a GET request to that URL. This works fine, except Amazon has no idea it's me who's sending the request, because I haven't authorized my NodeJS application.
I've successfully copied ~10 cookies from my regular browser into an incognito tab and authorized that way, so I know copying the cookies will work. After adding them all using tough-cookie, it didn't work, unfortunately. I still got redirected to the signin page (according to the error response).
How do I authorize for this API, so I can send my requests?
I have been looking for a solution for this too. The best idea I have is to use account linking, but I haven't try it yet. Looks like ASK-CLI has interface for this also, but I can't figure it out how to use it (what is that URL?). For linking account to 3rd party server is not easy, but link it back to Amazon for the json API should not be that complicated.
I am using Instagram's API which requires OAuth2 have some questions regarding best practice for setup. For more details here: https://www.instagram.com/developer/authentication/
So a user clicks on a login button and I give a redirect href.
Log In
They then receive a popup sign in, and they have the option of signing in or not. They are then redirected and '?code=zzzzzzz'is appended to the url: "http://localhost:8080?code=zzzzzzz"
Then the instructions read:
Now you need to exchange the code you have received in the previous step for an access token. In order to make this exchange, you simply have to POST this code, along with some app identification parameters, to our access_token endpoint.
But how should I do this? I'm using Express on the backend. To serve the frontend I use this line:
var static_path = path.join(__dirname, './../build');
It isn't an API route, so I can't use the normal
app.get('/?code=zzzzzzz', function(req, res) {...}).
So how can I use the code that I received in the params?
You must change your redirect_uri on isntagram to something like:
/auth/instagram/callback
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=http://localhost:8080/auth/instagram/callback&response_type=code
Then you can get your code with req.query.code from inside the controller.
For posting the code to isntagrams API use "request" library for nodejs
okay.
I think I have failed to understand an elemental part of token based authentication.
I am using node with express and am using jwt to prevent access to my site if you haven't logged in. I can create a token on the login page, and I can send it back to the client and store it in localStorage/cookie. Now if the user wants to navigate to another page they will type in a url and trigger a get request.
How do I access that token from localStorage/cookie and pass it to the server before I load the page as part of the get request. My assumption is that there should be a way of passing the token to the server - intercepting it in the middleware - and loading the page if the token is legit, or redirecting to the login page if the token isn't validated correctly.
On a post request this would be much simpler as you can fetch the token and pass it as part of an ajax call, after the page has loaded.
I have seen references to including the token as part of the request header (authorization bearer). I assume this only works for post, because if you were able to set the header parameter 'globally' then why would you bother storing on the client side in a cookie/localStorage.
So as you can see I am a little confused by the workflow. It seems like I am going against the grain somehow. Any clarity would be much appreciated.
If you are using localStoage in order to store the JWT, then the easiest way to pass it to the server is by retrieving first the token from the localStorage with localStorage.getItem('token') (or whatever your token name is) and then inserting it in the header of the request (either it is GET or POST/PUT/DELETE). Depeding on the library you are using to handle your http requests on the client, there are different ways of doing so. In jQuery for example, you can do the following inside the AJAX request:
$.ajax({
url: API_URL + "/endpoint",
method: "GET",
beforeSend: function(request){
request.setRequestHeader("Authorization", "BEARER " + localStorage.getItem('token'));
}
})
After this, on the server side simply access the parameters by accessing request.header options just as you would normally do. Hope this helps!