I try to call vimeo API from browser's javascript. When I try to get access token (POST https://api.vimeo.com/oauth/access_token) I get 405 response and CORS error.
Is it possible to make API calls from browser?
Generating access tokens are not currently supported in the browser. Eventually they will be in a very specific circumstance.
For now you need to generate your access token serverside and share it with the client. Be careful though, these tokens do not have an expiration so your clients can take them and use them forever.
We will be fleshing out support for browser-based API calls in the future, but it's still a while out.
Related
I sniffed the network traffic coming out of an app that displays real time data. I am trying to get access to the api to display the same real time data on a website that I am working on currently. I was able to view the get request and the response using fiddler and I then sent a get request directly using the url. However, my get request was blocked by CORs policy. I'm a beginner and would like to know how to access the API.
If the server that's hosting the API doesn't supply COR headers that explicitly allow this, you're not going to be able to make these requests via your browser. I'd recommend making the requests on your server instead of in the browser, because that's not bound by CORs settings.
I'm attempting to use Google Sign-In with a firebase function following Google's documentation for Google Sign-In for server-side apps, however I'm running into a redirect_uri_mismatch error (unlike the examples in that documentation, I am using Google's nodejs SDK).
The general flow I'm following is to use google's javascript SDK to request an offlineAccessCode() from a user, send that access code to the server (firebase function), use the access code to get an access token and refresh token, and save the refresh token for later use (this is the flow outlined in the documentation).
It might seem like the meaning of the term redirect_uri_mismatch is self-explanatory, but, as stated in the linked documentation, The Authorized redirect URI field does not require a value. Redirect URIs are not used with JavaScript APIs. That line comes from the section "Step 1: Create a client ID and client secret" and is explaining how to configure the OAuth client credentials. This is the only time in the documentation that a redirect uri is mentioned, and there is no indication that a redirect URI is needed when the server uses the authorization code to fetch an access token.
Indeed, the concept of a redirect uri doesn't seem to make sense in the context of a cloud function using an access code obtained from a client. If the server needs to supply a matching redirect_uri as the javascript client (which doesn't seem to be specified anywhere), I'm not sure what redirect_uri the javascript client uses.
So with that background, does anyone have any idea how to solve this redirect_uri_mismatch error?
Or, more generally, any pointers on implementing this auth flow (my cloud function is written in javascript using the google nodejs sdk). I'm finding it very hard to debug this issue.
Update
I realized that the reason why the error message says redirect_uri_mismatch is because I had been testing various values as redirect_uri. When I remove the (optional) redirect_uri param from the request, the response from google's servers is invalid_request: Missing parameter redirect_uri. So google's making it clear that it wants a redirect URI, even as the documentation seems to imply that it isn't necessary for this auth flow. As a larger problem, the documentation doesn't seem to describe how to set up a redirect URI for an auth flow on a single page app.
Ah HA! The answer (as given in this other S.O. answer) is to set the redirect_uri to "postmessage" on the server (firebase function in my case). I have no idea where this answer came from (i.e. I haven't been able to find it in the docs), but it works.
I need to use several EWS requests (e.g. GetUserConfiguration, UpdateUserConfiguration) that are not supported using Office.context.mailbox.makeEwsRequestAsync.
I cannot use the EWS Managed API in my own web service as a broker, and must use XML SOAP requests directly from the add-in's JavaScript (those methods are not available in the Graph or Mail APIs).
There are many examples (like this) showing how getUserIdentityTokenAsync can be used to pass that token to your web service (again, which I can't use) to use there in whatever way you need it.
However, I'm guessing the token retrieved from getUserIdentityTokenAsync is different and cannot be used. As a simple and hopefully appropriate test, I obtained an OAUTH token for my O365 account and used that as the token using SOAPe for a test GetUserConfiguration call and it worked. I then tried using the token from getUserIdentityTokenAsync and it didn't work (401 Unauthorized).
I concede that this may be a poor test, and I admit that at this point it is unclear to me how a SOAP EWS request from JavaScript in an Outlook dd-in can be authenticated without requiring an explicit user login (hopefully it can). And if it can, how do I get the token I need and how do I use it for this kind of client-side request?
You may want to use ews-javascript-api helper in this case. here is the example on how to use this with Outlook Add-ins.
https://github.com/gautamsi/ews-js-api-browser#working-with-plain-jsts-no-module-loadersbundlers
you may use any allowed api (available in makeEwsRequestAsync) with this library. with similar api what is available in Ews managed Api.
I am trying to develop a chrome extension in which I need to use 3rd party Oauth2 authentication. The third party service I want to use, only supports POST requests. But it seems that the launchWebAuthFlow method in the Chrome Identity API, only supports sending GET requests, as all the query parameters are sent in the URL itself. Is this correct? If yes, how should I do authentication?
UPDATE : The API I want to connect is that of Pocket
Partially you're right about POST requirements. But it is only used to initialize Oauth flow.
According to the documentation:
1) You must make a POST request to obtain a request token from Pocket auth service
2) Redirect user to the auth page: https://getpocket.com/auth/authorize?request_token=YOUR_REQUEST_TOKEN&redirect_uri=YOUR_REDIRECT_URI
Which means that you have to make a simple XHR to retrieve request token and then you can use chrome.identity.launchWebAuthFlow function to begin Oauth flow.
Did you try launchWebAuthFlow? You may find that it works. Once authenticated, you can exercise the API via POST, using XMLHttpRequest. (launchWebAuthFlow only handles the authentication, not the API itself.)
I'm currently working in HTTP JSON API for a touristic webapp. The webapp will be developed by a third-party company and it'll consume the API within the browser.
So I need for the API some sort of authentication to the third-party webapp can consume it. I've been researching a little bit about OAuth, but with this, I have a solution for a user-wide but not for application-wide authorization.
Because the webapp will consume the API within the browser(with Ajax), I'm concerned they will have to put the credentials to consume the API in the user browser.
Another solution would be place the credentials for the API in the server-side, but this don't depend on me.
You could always use something similar to google's method, with a client ID and then a private key used to generate a signature.
https://developers.google.com/maps/documentation/business/webservices#generating_valid_signatures
That page has some code samples as well.