Aloha! Today, I'm trying to add custom headers to each request to my backend.
Playing with my DS.RESTAdapter, I already tried:
The 3 headers: solutions suggested in the official guide.
The 2 ajax: approaches proposed around there.
And 2 jQuery workarounds (based on $.ajaxPrefilter and $.ajaxSetup) that I found there.
Until now, my only result was this very obscure "Adapter operation failed" error:
{
details: "",
status: 0,
title: "The backend responded with an error"
}
I know that:
My backend behaves well and returns a 200 status (I tested sending the request via cURL).
Strangely, removing my adapter's host setting allows the request to be sent, but obviously at the wrong URL.
My problem is not a CSP issue as I'm currently running both backend & frontend locally.
According to my debugging and to my Network Inspector tab, the AJAX request is just never sent (XHR.readyStatus is stuck at 0).
Has somebody already faced this?
Any help would be really lovely!
Ember 1.13.11
Ember Data 1.13.15
jQuery 1.11.3
EDIT: Magic minimal app reproducing the bug is out here!
Hope you'll enjoy it! And because I love you so much, I also offered a demo API endpoint on my server. Details in the FM!
BONUS! Do you know what is the coolest thing to put in a clipboard?
git clone https://github.com/imbrou/ember-data-headers-demo.git
Yeeeeeeha! (-:
Usually "Adapter operation failed" error occurs because your application is having problems connecting to the backend, usually DS.RESTAdapter is not correctly setup, make sure your host and namespace are correct.
Example:
export default DS.RESTAdapter.extend({
host: 'http://193.137.170.210:8080',
namespace: '/api'
});
Solved !
My backend was not sending the correct CORS headers.
The tricky thing is that for an unknown reason, my version of Firefox (Developer Edition...) didn't display the failing OPTIONS request in my Network Inspector at the point of my debugging. I thus had no debugging information at all there.
I could only observe the failing preflight using... Wireshark !
It may have been a bug solved in a Christmas update, as I can't reproduce it today. Too bad...
Anyway, in desperation, I linked 3 screenshots:
No-preflight example: no backend security (no "authorization" token).
Working example: the "authorization" header is requested by client, and allowed by server in the response during the preflight.
Failing example: the "authorization" header is requested by the client, BUT not allowed by the server.
Hope it helps, thanks #Vítor for your support !
Related
When hitting https://login.salesforce.com/services/oauth2/token, using Postman.
POST https://login.salesforce.com/services/oauth2/token
Response:
I receive a token, but when I try to do something as simple as GET /limits,
GET https://na73.salesforce.com/services/data/v45.0/limits
the response is:
[
{
"message": "Session expired or invalid",
"errorCode": "INVALID_SESSION_ID"
}
]
The strange thing is that when I change all my credentials to a free "developer account" created with a different email address, everything works fine. All requests and headers are the exact same, with the exception of the values from either account.
After digging through a lot of threads on here I thought that maybe my production account (the one I'm posting from now) was not API ENABLED. It turns out my production account is API ENABLED.
I also tried changing https://login.salesforce.com/services/oauth2/token to https://na73.salesforce.com/services/oauth2/token as some threads have suggested, but that just times out.
When comparing both account permissions, they seem identical and I've confirmed I have no issues with the credentials (client id, client secret, security token, access-token), all of them seem to be copied in correctly.
Any ideas for a salesforce noob?
I actually fixed this after banging my head on it forever. You need to go into the settings tab and turn on the Follow Authorization Header setting.
I'm here in 2021 and for me the solution was not 'Follow Authorization Header', but the access token had a different instance_url than expected. Use this instance_url value in _endpoint and you are fine.
After fighting with this for a few days, I've ruled out this is an issue with Postman. What garbage. Just follow https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/quickstart_code.htm and use curl commands instead. If I copy a raw curl command into postman then run, it continues to fail with INVALID_SESSION_ID, but works fine in ZSH
So much for a useful GUI
In my case, the _endpoint variable was not getting set after successfully authorising via the browser (should that not happen automatically?), so I had to set it manually -- but, I put the wrong URL for it (
https://whatever.lightning.force.com instead of
https://whatever.my.salesforce.com),
so I would get a 302 redirect to the correct URL, but then that one would return this message.
So changing the _endpoint variable to the correct URL fixed it for me.
I had the same issue, even when activating the Follow Authorization Header
Basically, the Authorisation Bearer is not set directly, so I added it in the Pre-request script tab
pm.request.headers.add({key: 'Authorization', value: 'Bearer {{_accessToken}}' });
Works like a charm now.
So this is my current code
When I delete the Authorization from the headers the request will be successful, and i get the response. But when I use the Authorization header, it will give me this error.
The server is using Python Django and using this libary for CORS Handling
EDIT 1: This is the python server settings
EDIT 2: Add Browser
I use Chrome Version 53.0.2785.143 m (64-bit)
EDIT 3: Postman response
Just got weird response here. When the backend guy tried from his laptop, he got the complete header. like this:
But when i use my laptop, i got this response:
I'm guessing cors is not allowing the Authorization header. So, lets add that the Authorization entry to CORS_ALLOW_HEADERS
CORS_ALLOW_HEADERS = (
...
'Authorization',
...
)
Solved!
It's caused by the App Enlight plugin for monitoring. When I remove it, everything works without errors :)
I am trying to load info from the uber API using javascript on a web page.
Well, basically I am playing with this tutorial, but I am getting Access-Control-Allow-Origin errors.
I have my CLIENT ID and SERVER TOKEN, and I left most of the other options blanked.
I tried to host it in the localhost and filled http://localhost:8000 in the ORIGIN URI but with no luck.
For the page https://kylelam.github.io/final-section/, I tried filled in https://*, https://kylelam.github.io, and https://kylelam.github.io/*, with combination of with and without dataType: 'jsonp', but I am still having trouble figuring out what went wrong.
Try this in meantime as workaround CORS issue
http://crossorigin.me/
Unfortunately, port numbers for localhost will not correctly show up in the Access-Control-Allow-Origin header, even after setting the Origin URI field for your app. This is a known issue that we hope to fix soon.
I'm trying to use jquery.couch.js to do couch operations in my ember.js app, but I'm having cors problems, and I have no clue what a good solution is.
It seems to me that couch running on port 5984 would make it basically unusable? Why do requests to different ports cause cors problems? And how on earth do OTHER people end up getting couch to work? I'm immensely confused, and not sure how to proceed.
My couch instance returns this from curl:
{"couchdb":"Welcome","version":"1.2.0"}
The code I'm unsuccessfully trying to run is this:
$.couch.urlPrefix = "http://127.0.0.1:5984";
$.couch.login({
name: 'name',
password: 'secret'
});
I've modifed the urlPrefix part several times to things like localhost and removing the http:// for both versions.
The error it's throwing:
XMLHttpRequest cannot load http://127.0.0.1:5984/_session. Origin http://localhost is not allowed by Access-Control-Allow-Origin.
Help me! I humbly recognize my noobiness for saying this, but how is couchdb even useful if this is built right into the basic functionality?
Oh and I'm including jquery.couch.js like this:
<script src="http://localhost:5984/_utils/script/jquery.couch.js"></script>
Using this version of jquery:
jQuery JavaScript Library v1.10.2
and using jquery migrate because of previous issues:
<script src="http://code.jquery.com/jquery-migrate-1.2.1.js"></script>
Edit
I just now tried to add crossDomain: true, xhrFields: {withCredentials: true} to my login call, to no avail. Exact same error message. I'm clearly missing a core concept.
The message you are seeing is referring to the server, not the client. Changes made to the client's call will not, as you reported, change the result.
In CouchDB 1.4 specifically, CORS support must be explicitly enabled and an origins declaration must be made. That said, depending on how you are using your CouchDB instance there are two ways to enable it:
Change the setting in your local.ini directly and restart your instance, see here for more info: http://wiki.apache.org/couchdb/CORS
In the case you have futon available, go to Settings and find the setting there and enable it, in this case no restart is needed.
Update
It seems that the CORS section is not always existent by default, in this case just add it yourself.
Hope it helps.
For those who are using Cookie authentication (not password authentication) and are reusing the cookie in the Ajax request returned by the CouchDB server, you still need to do this in your $.ajax() requests to CouchDB:
xhrFields: {withCredentials: true},
Which, means you have to open the jquery.couch.js file that you sourced from the couch server and manually insert that option into the javascript.
CORS didn't work for me without both doing this on the client side and setting "credentials=true" on the server side.
The original jquery.couch.js as it is written right now doesn't support the client side sending Cookies with CORS, so you have to do it yourself until someone opens a ticket to get this fixed.
I'm hoping someone can answer this question for me, I'm not an expert on servers so please excuse me if I'm completely off base.
I'm using Android webview (PhoneGap 1.4.1) to make Ajax calls but I keep getting a ready state 4 status 0 on each call. I've spent the last couple hours investigating this and I may have figured out why. I used xhaus.com/headers to check my requests and found that in web view my "Accept" header is:
text/xml, text/html, application/xhtml+xml, image/png, text/plain, /;q=0.8
however, if I pull up the Android browser and check my header that way, I see that my "Accept" header is:
application/xml, application/xhtml+xml, text/html;q=0.9, text/plain;q=0.8, image/png, /;q=0.5
I checked the server that is providing the XML and found that the return heads are "Content-Type" is set to:
application/xml
My first question is: Webview doesn't seem to support "application/xml" type, so could this be the reason I'm having my issue? Or am I completely off base here?
Second question: Is there anything I can do on the client side to fix this or will the server admin need to make the change? I am using GET to make the request.
Third question: Is this normal? why would web view / browser have this sort of mismatch?
My app has been tested on 10+ handsets and only 2 have this issue... Very strange.
Thank you,
I may be wrong, but it sounds like you're calling a web service? Some services support mutliple calling strategies depending on the content-type header that you pass.
For example SharePoint web services support both SOAP 1.0 (if Content-type is sent as "text/xml; charset=utf-8") and SOAP 1.2 (if Content-type is set as "application/soap+xml").
In your case I would try setting a content-type of "text/xml; charset=utf-8" and see what happens.
As for the "accept" header if the server response isn't acceptable based on the passed value it should pass a status of 406 (not acceptable). It may simply be a bug in the server or in any of the steps between tho' that it's not. Using a tool like Fiddler you should be able to recreate both requests (both variations on "accept") and see exactly what the server responses with however - that may be the easiest way to truly get to the bottom of things.