I am currently in the process of implementing a server-side OAuth2 flow in order to authorize my application.
The JS application will be displaying YouTube Analytics data on behalf of a registered CMS account to an end user (who own's a channel partnered with the CMS account). As a result of this, the authorization stage needs to be completely hidden from the user. I am attempting to authorize once, then use the 'permanent' authorization code to retrieve access tokens as and when they're needed.
I am able to successfully authorize, and retrieve an access code. The problem begins when i attempt to exchange the access code for a token.
The HTTP POST Request to achieve this needs to look like this...
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-Type: application/x-www-form-urlencoded
code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=8819981768.apps.googleusercontent.com&
client_secret={client_secret}&
redirect_uri=https://oauth2-login-demo.appspot.com/code&
grant_type=authorization_code
I am using this code to achieve this:
var myPOSTRequest = new XMLHttpRequest();
myPOSTRequest.open('POST', 'https://accounts.google.com/o/oauth2/token', true);
myPOSTRequest.setRequestHeader('content-type', 'application/x-www-form-urlencoded');
myPOSTRequest.send('code=' + myAuthCode + '&redirect_uri=http%3A%2F%2Flocalhost%2FCMSAuth3.html&client_id=626544306690-kn5m3vu0dcgb17au6m6pmr4giluf1cle.apps.googleusercontent.com&scope=&client_secret={my_client_secret}&grant_type=authorization_code');
I can successfully get a 200 OK response to this Request however no access token is returned, and myPOSTRequest.responseText returns an empty string.
I have played with Google's OAuth Playground - and can successfully get a token using my own credentials.
Am i missing something here?
You cannot do this, because there is the same origin policy. This is a security concept of modern browsers, which prevents javascript to get responses from another origin, than your site. This is an important concept, because it gives you the ability, to protect you against CSRF. So don't use the code authorization flow, use instead the token authorization flow.
Try and build up the full URL. Then dump it in a webbrowser. If its corect you will get the json back. You have the corect format.
https://accounts.google.com/o/oauth2/token?code=<myAuthCode>&redirect_uri=<FromGoogleAPIS>&client_id=<clientID>&client_secret={my_client_secret}&grant_type=authorization_code
Other things to check:
Make sure that you are using the same redirect_uri that is set up in google apis.
How are you getting the Authcode back? If you are riping it from the title of the page i have had issues with it not returning the full authcode in the title try checking the body of the page. This doesnt happen all the time. I just ocationally.
Related
I am using caspio rest api to authenticate my users in a mobile app. Upon authenticating, I was given an access token to which I included in my AJAX call under the parameter 'Authorization' : Bearer [access token].
I understand that I can renew the token with the refresh token given to me where I can use the POST call.
My question is: prior to using the POST call for a new token, must I store the access token?
Also, the Caspio website advised this format for the POST call:
Method: POST
URL: Token Endpoint
Body: grant_type=refresh_token&refresh_token= [token value]
Header parameters:
Authorization: Basic [string "Client_ID:Client_Secret" encoded in Base64]
Content-Type: application/x-www-form-urlencoded
Should I also include the client ID and client secret in the parameters? Upon using Firefox's rest client, I'm getting a bad request (400) error.
Thank you for the help!
I never using caspio rest api before. The answer base on my OAuth experiences.
My question is: prior to using the POST call for a new token, must I store the access token?
YES! The OAuth 2.0 using the access token to switch the refresh token at first time.
Should I also include the client ID and client secret in the parameters? Upon using Firefox's rest client, I'm getting a bad request (400) error.
According to the api document. You should include the client ID and client secret in your request, like most OAuth 2.0 do.
The bad request (400) error you may see the rfc6749 to find further information.
I'm trying to get information about videos hosted by Vimeo (from my client's channel, so no rights issues). I'm using Javascript, specifically d3.js.
The request works fine when using the old API, with this type of url :
http://vimeo.com/api/v2/video/video_id.output
For instance, this works in d3.js :
d3.json("http://vimeo.com/api/v2/video/123456789.json", function(error,data){
console.log(data);
}):
But I can't get the new API to work as easily in a simple request, using this type of url for instance :
https://api.vimeo.com/videos?links=https://vimeo.com/123456789
What do I need to do ? Authenticate ? If so, how ? I'd be grateful to get examples in either jQuery of d3.
Vimeo's API documentation is not the best, so you have to dig a little around to actually get the information you need. In your case, you do not need to go through the whole OAuth2 loop if you are simply requesting data from endpoints that do not require user authentication, such as retrieving metadata of videos, as per your use case.
First, you will need to create a new app, by going to https://developer.vimeo.com/apps:
You can simply generate a Personal access token from your Vimeo app page under the section that says Generate an Access Token:
Remember that this token will only be visible once (so copy it when it is generated): and you have to keep it secure! The access token should be part of the Authorization header's bearer token. If you are using cURL, it will look like this:
curl -H "Authorization: Bearer <YourPersonalAccessToken>" https://api.vimeo.com/videos/123456789
Therefore, while you can do the following on your page to retrieve video metadata on the clientside, note that you are actually exposing your private token to the world:
d3.json("https://api.vimeo.com/videos/123456789/")
.header("Authorization", "Bearer <YourPersonalAccessToken>")
.get(function(error, data) {
console.log(data);
});
However, I strongly recommend that you proxy this request through your own server, i.e. create a custom endpoint on your server, say /getVimeoVideoMetadata. This API endpoint will receive the video ID, and will add the secretly stored access token you have on your server before making the request. This will mask your access token from your website visitors.
I am trying to access Adyen test API that requires basic authentication credentials. https://docs.adyen.com/developers/ecommerce-integration
My credentials work when accessing the API page through browser.
But I get an 401 Unauthorized response when trying to access the API with XMLHttpRequest POST request.
Javascript Code
var url = "https://pal-test.adyen.com/pal/servlet/Payment/v25/authorise";
var username = "ws#Company.CompanyName";
var password = "J}5fJ6+?e6&lh/Zb0>r5y2W5t";
var base64Credentials = btoa(username+":"+password);
var xhttp = new XMLHttpRequest();
xhttp.open("POST", url, true);
xhttp.setRequestHeader("content-type", "application/json");
xhttp.setRequestHeader("Authorization", "Basic " + base64Credentials);
var requestParams = XXXXXXXX;
xhttp.send(requestParams);
Result
That screenshot shows “Request Method: OPTIONS”, which indicates the details displayed are for a CORS preflight OPTIONS request automatically made by your browser—not for your POST.
Your browser doesn’t (and can’t) send the Authorization header when it makes that OPTIONS request, and that causes the preflight to fail, so the browser never moves on to trying your POST.
As long as https://pal-test.adyen.com/pal/servlet/Payment/v25/authorise requires authentication for OPTIONS requests, there’s no way you can make a successful POST to it.
The reason is because what’s happening here is this:
Your code tells your browser it wants to send a request with the Authorization header.
Your browser says, OK, requests with the Authorization header require me to do a CORS preflight OPTIONS to make sure the server allows requests with that header.
Your browser sends the OPTIONS request to the server without the Authorization header—because the whole purpose of the OPTIONS check is to see if it’s OK to send that.
That server sees the OPTIONS request but instead of responding to it in a way that indicates it allows Authorization in requests, it rejects it with a 401 since it lacks that header.
Your browser expects a 200 or 204 response for the CORS preflight but instead gets that 401 response. So your browser stops right there and never tries the POST request from your code.
The PAL is a Payment Authorisation API. You never want to call it from a browser. You only want to expose your username and password to send in payments in your backend code.
In Client-side encryption, the encryption is done in the browser. You then send the encrypted data to your own server. On your server you then create a payment authorization request (of which the encrypted data is one of the elements, along side payment amount, etc).
If you would be able to manage to make this run from your browser, your end solution will allow your shoppers to change amounts, currency's, payment meta data etc from the JavaScript layer. This should never be the case.
The authorization is for that reason part of the "Server side" integration part of documentation: https://docs.adyen.com/developers/ecommerce-integration?ecommerce=ecommerce-integration#serverside
Depending on your server side landscape the CURL implementation in your favorite language differs, but most of the time are easy to find.
Kind regards,
Arnoud
I'm trying to create a web page that sends an email only using javascript and Gmail API. I have set up my developer's console to use the API and also created an API key and a credential.
I have adapted this example code, and so far I think I got to the point of loading the GMail API. (or.. 400 means something is wrong?) The console log shows:
POST https://content.googleapis.com/gmail/v1/users/me/messages/send?alt=json 400 (OK)
zu # cb=gapi.loaded_0:85
n # cb=gapi.loaded_0:85
Cu # cb=gapi.loaded_0:85
(anonymous function) # cb=gapi.loaded_0:86
g # cb=gapi.loaded_0:55
c # cb=gapi.loaded_0:46
And when I try authenticating with oAuth2.0 through a url:
var code;
$.get("https://accounts.google.com/o/oauth2/auth?scope=email&
redirect_uri=http://hiro.collegewebserver.com/COSW200/hw13/gmailtest.html&
response_type=token&client_id=386373199858-o1rt7qj3gt99gbfg6pqpr0g6i92urq9t.apps.googleusercontent.com&
approval_prompt=force",
function (returnedValue) { code = returnedValue; });
I get this message:
XMLHttpRequest cannot load https://accounts.google.com/o/oauth2/auth?scope=email&
redirect_uri=http://h…3gt99gbfg6pqpr0g6i92urq9t.apps.googleusercontent.com&
approval_prompt=force.
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://hiro.collegewebserver.com' is therefore not allowed access.
I've read other posts that say this may be due to cross origin requests being blocked? Someone wrote that there are ways to work around this like using JSONP?
If someone can enlighten me as to what I'm missing here, I would really appreciate! :)
You cannot make an ajax call to Google to get your access code. The idea of OAuth2 is that you first redirect the user to accounts.google.com/o/oauth2/your_settings. In your case:
https://accounts.google.com/o/oauth2/auth?scope=email&redirect_uri=http://hiro.collegewebserver.com/COSW200/hw13/gmailtest.html&response_type=token&client_id=386373199858-o1rt7qj3gt99gbfg6pqpr0g6i92urq9t.apps.googleusercontent.com&approval_prompt=force
In this Google environment the user can login with his/her account. One of the settings you provide is the redirect_uri.
Since you whitelisted http://hiro.collegewebserver.com/COSW200/hw13/ as one of the Authorized redirect URIs in your Google Developers Console and this url is related to your client_id, no other application than your website can use your client_id to receive an authorization code.
After login the user will be redirected to this redirect_uri, with the code as one of the parameters.
This will look something like this:
http://hiro.collegewebserver.com/COSW200/hw13/#access_token=yb27…jK0AVtilhnrJDcuTISgIB5LiNtKLMut1kVvPW69w&token_type=Bearer&expires_in=3600
After that you would have to extract the access token from the url. With this access token you can authorise the user and make use of the scopes you entered. This can be done with an ajax call.
$http({
method: 'GET',
url: 'https://www.googleapis.com/upload/gmail/v1/users/userId/messages?access_token=' + access_token
}).then(function(response){
//your code
})
You could also put the access_token in the header of the call:
Authorization: Bearer access_token
Another option is to use the API Client Library for JavaScript (Beta): https://developers.google.com/api-client-library/javascript
Although it is in Beta and the basic workflow is the same, it might give you clearer examples.
I want to use the new vimeo api to fetch videos based on a query, but I getting a 401 Authorization Required with this message "error": "A valid user token must be passed."
I'm using this code :
var urlX = 'https://api.vimeo.com/videos?query=elvis&client_id='+VIMEO_API_KEY;
$.getJSON(urlX, function(data){
console.log(data);
});
So obviously I have an authentication problem.
As client_id I'm using my "Client Identifier" from my app created in Vimeo's dashboard.
The error I keep getting mention "user token", do I have to generate one via Vimeo's dashboard or via php ?
I'm a bit lost here.
client_id through the querystring is not a valid method of making API calls against the Vimeo API.
First you must request an access token either through the oauth2 redirect worfklow: https://developer.vimeo.com/api/authentication, or by generating it on your app page.
Second you must provide that access token with your api request either through the Authorization header:
Authorization: bearer <your_token>
or the querystring
https://api.vimeo.com/videos?query=elvis&access_token=<your token>.
The authorization header is more secure, and will continue to work indefinitely. Some changes will be made soon to the querystring form which could cause problems with your application.