I'm building a small web app with Ember.js and Firebase so as of now I don't have a framework. I'm trying to use Venmo's OAuth and API to get usernames, emails, and friends. I got OAuth to work and I get a client-side access token to use in an API call, but whenever I try and send a GET to https://api.venmo.com/v1/me?access_token=<access_token> using AJAX or CORS I get an error saying XMLHttpRequest cannot load https://api.venmo.com/v1/me?access_token=<access_token>. No 'Access-Control-Allow-Origin' header is present on the requested resource. Is there a way to do this with javascript
I'm an API engineer over # Venmo, and we're looking to open up CORS support very soon, in the next couple months hopefully. Feel free to email developer#venmo.com and bug us if you need to :P
Related
I am making an app for shopify, that would allow costumers to send a message to a sites owner.
For this i have made a little server that would send the email on a post request.
Naturally, shopify would not let me do this. Instead, I am getting a cors, cross origin request issue. So I have created a private app, but they don't appear to provide me with the ability to make a post request to my server.
So I am looking into making a public unlisted app. But I am a bit burned out from my last attempt and am not in the mood to go off implementing oauth (for the first time) just to find out that I am still not getting the functionality that I need.
Can anyone please tell me what are the minimum requirements for me to be able to whitelist my server for ajax requests from the client side?.
I am having a web-app (serverless) that I am using for a long time. The idea is that the app gets contacts from my Google Account, and then I can do some actions by using this data.
Unfortunately, last days I started to recieve CORS errors... I didn't pay attention, but today I tried to fix it. And I realized that all other Google APIs like maps, locations, OAuth work properly.
The only problematic one is the Google Contacts API. I wonder, it's possible to continue using this API on the client side? I didn't touch the code and google-cloud settings. This is a very strange behavior...
Failed to load https://www.google.com/m8/feeds/contacts/default/full?v=3.0&alt=json&access_token=......&updated-min=2018-08-09T22%3A00%3A21.000Z&max-results=500:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://.....' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
The issue is fixed on Google's side (was a bug).
I'm building an MVC web app that uses the openID Connect hybrid flow to authenticate with Identity Server 3. The MVC web app contains jQuery scripts to get async JSON data from een ApiController. That ApiController is part of the same MVC web app.
I don't want that everyone is able to access the data from the API, so I want to secure the API as well. I added an [authorize] attribute to the ApiController. When requesting the API with a JQuery ajax request I get the following error message:
XMLHttpRequest cannot load
https://localhost:44371/identity/connect/authorize?....etc.
Response to preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://localhost:13079' is therefore not allowed
access. The response had HTTP status code 405.
But, when I do a request to the API method directly in browser, I will be correct redirected to the Login page of Identity Server..
So, what's exactly the problem here? I read something about that requesting the /authorize endpoint is not allowed via 'back-channel', but I don't understand what's the difference between 'front-channel' and 'back-channel'. Is it possible that I mixed up the wrong OAuth flows? Is the Hybrid flow not the correct one maybe?
I also find out that the API is often a seperate app, but is it always neccessary / best-practice to build a seperate API app that for example requires a bearer token?
Please point me in the right direction about this.
The authorize method on your identity server does not allow ajax calls. Even specifying CORS headers is not going to help you in this particular case. Perhaps you could return a forbidden response instead of a redirect and manually redirect the client to the desired location via window.location
You need to allow your IdentityServer to be accessed from other domains, this is done by allowing "Cross Origin Resource Sharing" or CORS for short. In IdentityServer the simplest way to allow this is in your Client configuration for your Javascript Client, see this from the IdentityServer docs on CORS:
One approach to configuing CORS is to use the AllowedCorsOrigins collection on the client configuration. Simply add the origin of the client to the collection and the default configuration in IdentityServer will consult these values to allow cross-origin calls from the origins.
The error you're seeing is the browser telling you that when it asked IdentityServer if it allows requests from your Javscript client, it returned a response basically saying no, because the origin (http://localhost:13079) was not specified in the "Access-Control-Allow-Origin" response header. In fact that header wasn't in the response at all meaning CORS is not enabled.
If you follow the quickstart for adding a JavaScript client from the docs here all the necessary code is detailed there that you need for the Client config and to setup IdentityServer to allow CORS.
I am trying to hit USPS address validation API by AJAX call and I am getting 'Cross-Origin Request Blocked' error.
However when I am trying to access the same address though URL, I am getting the results.
Has this error something to do with approval thing?
The id I am using for this has been approved and I am able to get the result by the API through URL.
I want to access it though scripting. Please help.
Any help would be appreciated.
Thanks in advance.
I think the way you might want to do this is to have the Ajax requests go to your web server -- the same HTTP server where the page came from. And then your server-side program (in PHP, or Python or whatever you're using) relays the request to the USPS server.
Making the request browser-side, from Ajax directly to the USPS server, is just the kind of suspicious activity (called Cross-Site Scripting) that browsers are learning to block.
CORS could theoretically be one way to unblock a Cross-Origin Request, but in that scheme it would be the USPS API server that ultimately grants that permission for pages from your domain. Tech detail: by inserting an Access-Control-Allow-Origin header in response to a request with an Origin header in the Ajax back-and-forth.
For applications that authenticate users with Windows Azure Active Directory(WAAD), unable to refresh token from javascript.
All the resources are protected by Authorize attribute makes calls to login.windows.net/{0} if token is expired. If the request is from page load it works as expected but if the request is from javascript ajax call it is unable make call to login.windows.net/{0}. It returns with status 302 and message
XMLHttpRequest cannot load https://login.windows.net/xxx.
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'xxx' is therefore not allowed access.
How to refresh the token from javascript calls?
It looks like you secured your web API with a method more suited for web UX.
Take a look at ADAL JS for a more reliable way of dealing with javascript driven apps: http://www.cloudidentity.com/blog/2014/10/28/adal-javascript-and-angularjs-deep-dive/
For an explanation of how token renewal works, see the video linked in that post
HTH
V.