I am building an application in which server authenticates client's token and generates an Application token for further use.
I use curl to make sure everything works fine.
curl -XPOST -v -H "X-ID-TOKEN:eyJhbGciOiJSUzI1NiIsImtpZCI6ImIyYmRjZDkyNGZhNWI1ZThhYjkwNTQ3M2ZjZTYxMGU3MWU0MjJlNmQifQ.eyJpc3MiOiJodHRwczovL3NlY3VyZXRva2VuLmdvb2dsZS5jb20vc3RhZ2luZy1wZW5ueXRyYWsiLCJuYW1lIjoiSGFyaXQgSGltYW5zaHUiLCJwaWN0dXJlIjoiaHR0cHM6Ly9saDQuZ29vZ2xldXNlcmNvbnRlbnQuY29tLy1fbFhqMk9VbVRuZy9BQUFBQUFBQUFBS
S9BQUFBQUFBQUFDTS9YYU5jMTJadGV5OC9waG90by5qcGciLCJhdWQiOiJzdGFnaW5nLXBlbm55dHJhayIsImF1dGhfdGltZSI6MTUwMTczMTc2MSwidXNlcl9pZCI6InJ4WjZtb240MGhhN1J5SDVpSEFPSHkxN0hrbzEiLCJzdWIiOiJyeFo2bW9uNDBoYTdSeUg1aUhBT0h5MTdIa28xIiwiaWF0IjoxNTAxNzMxNzYyLCJleHAiOjE1MDE3MzUzNjIsImVtYWlsIjoiaGFyaXQuc3Vic2NyaXB0aW9uc0BnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZmlyZWJhc
2UiOnsiaWRlbnRpdGllcyI6eyJnb29nbGUuY29tIjpbIjEwMDIxNjY5NjgzMjQ3MDQzMTUwNyJdLCJlbWFpbCI6WyJoYXJpdC5zdWJzY3JpcHRpb25zQGdtYWlsLmNvbSJdfSwic2lnbl9pbl9wcm92aWRlciI6Imdvb2dsZS5jb20ifX0.oWWug78iVJITZsJdA7npwjaG_CFnhQahwWCjnkz8Vi2famuTL61s8_Shx4oZVbKzju-L7ebEC4MSOvMc3HeEUwiwt9SunOo8JWfzwgpDbVzFTlnHu5OUeESssniXY4EyAF0uvI6jh1zoEz4SbPO-D87RXMNZYo69c6PFJVDYv--0sm4M7Ajmh7ynMmoEMH0pzjh-7l91yRguO5piQE9GQYwWe9-Jj8YlqWMnMa69M_jMrE14fMCB2mjoa9jJvZR1a-ao8LqO1U1FO64mzgf55yG8OS7aGVDN7gLxk1-RcqLxJogo0BDqsrdDykoeGHb1UflQP7dtazc47r3flELBGw" "http://loc
alhost:8080/login"
* Trying ::1...
* Connected to localhost (::1) port 8080 (#0)
> POST /login HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.43.0
> Accept: */*
> X-ID-TOKEN:eyJhbGciOiJSUzI1NiIsImtpZCI6ImIyYmRjZDkyNGZhNWI1ZThhYjkwNTQ3M2ZjZTYxMGU3MWU0MjJlNmQifQ.eyJpc3MiOiJodHRwczovL3NlY3VyZXRva2VuLmdvb2dsZS5jb20vc3RhZ2luZy1wZW5ueXRyYWsiLCJuYW1lIjoiSGFyaXQgSGltYW5zaHUiLCJwaWN0dXJlIjoiaHR0cHM6Ly9saDQuZ29vZ2xldXNlcmNvbnRlbnQuY29tLy1fbFhqMk9VbVRuZy9BQUFBQUFBQUFBSS9BQUFBQUFBQUFDTS9YYU5jMTJadGV5OC9waG90by5qcGciLCJhdWQi
OiJzdGFnaW5nLXBlbm55dHJhayIsImF1dGhfdGltZSI6MTUwMTczMTc2MSwidXNlcl9pZCI6InJ4WjZtb240MGhhN1J5SDVpSEFPSHkxN0hrbzEiLCJzdWIiOiJyeFo2bW9uNDBoYTdSeUg1aUhBT0h5MTdIa28xIiwiaWF0IjoxNTAxNzMxNzYyLCJleHAiOjE1MDE3MzUzNjIsImVtYWlsIjoiaGFyaXQuc3Vic2NyaXB0aW9uc0BnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZmlyZWJhc2UiOnsiaWRlbnRpdGllcyI6eyJnb29nbGUuY29tIjpbIjEwMDIxNjY5
NjgzMjQ3MDQzMTUwNyJdLCJlbWFpbCI6WyJoYXJpdC5zdWJzY3JpcHRpb25zQGdtYWlsLmNvbSJdfSwic2lnbl9pbl9wcm92aWRlciI6Imdvb2dsZS5jb20ifX0.oWWug78iVJITZsJdA7npwjaG_CFnhQahwWCjnkz8Vi2famuTL61s8_Shx4oZVbKzju-L7ebEC4MSOvMc3HeEUwiwt9SunOo8JWfzwgpDbVzFTlnHu5OUeESssniXY4EyAF0uvI6jh1zoEz4SbPO-D87RXMNZYo69c6PFJVDYv--0sm4M7Ajmh7ynMmoEMH0pzjh-7l91yRguO5piQE9GQYwWe9-Jj8YlqWMnMa69M_jMrE14fMCB2mjoa9jJvZR1a-ao8LqO1U1FO64mzgf55yG8OS7aGVDN7gLxk1-RcqLxJogo0BDqsrdDykoeGHb1UflQP7dtazc47r3flELBGw
>
< HTTP/1.1 200
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: DENY
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: origin, content-type, accept, authorization, bearer, x-id-token
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
< Access-Control-Max-Age: 1209600
< Authorization: Bearer eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJyeFo2bW9uNDBoYTdSeUg1aUhBT0h5MTdIa28xIiwiZXhwIjoxNTAyNTgyNDAwfQ.o3aw_ozg813jga6TdCvtV1mMJngO6f4Wgy2dYm4G7O2G6LvYADzIafXJn0Wmvw8-f5scDcmTf6wT_zyMHIDFRg
< Content-Length: 0
< Date: Thu, 03 Aug 2017 03:55:50 GMT
<
* Connection #0 to host localhost left intact
As you can see, the server sends back the Authorization header to the client.
On my Javascript application, my code to interact with server looks like
Api.js
let getAppToken = (idToken) => {
return fetch("http://localhost:8080/login", {
method: "POST",
headers: {
"X-ID-TOKEN": idToken
}
});
};
module.exports = {
getAppToken: getAppToken,
};
Which is used in my React component as
Login.js
console.log("idToken:", idToken);
getAppToken(idToken)
.then((response) => {
response.headers.forEach((val, key) => {
console.log(key, val)
});
});
When I run this React application, the only headers I see are
cache-control no-cache, no-store, max-age=0, must-revalidate
expires 0
pragma no-cache
Why don't I see the remaining headers sent by server? How can I fix this situation?
Thanks
The server must be configured to send an Access-Control-Expose-Headers response header that includes "Authorization" in its value if you want the browser to allow your requesting frontend JavaScript code to access the Authorization response header value.
If the response includes no value for the Access-Control-Expose-Headers header, the only response headers that browsers will let you access from client-side JavaScript in your web app are Cache-Control,
Content-Language,
Content-Type,
Expires,
Last-Modified
and
Pragma.
See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name for the spec on that.
Related
I get some data from an endpoint (the origin and endpoint domains are different).
I need to get some information from the custom response header. On the server side, this custom response header was added in the Access-Control-Allow-Headers header.
Applied response headers. Response body is ReadableStream
Some-Header: attachment; filename="some-name.tar"
Access-Control-Allow-Headers: Some-Header
Date: Thu, 03 Nov 2022 17:11:04 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive
X-Request-ID: d331a838-b22b-41c1-a5c9-bf3461129a97
Access-Control-Allow-Origin: *
X-RateLimit-Limit: 50
X-RateLimit-Remaining: 49
X-RateLimit-Reset: 1667495466
X-DNS-Prefetch-Control: off
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Download-Options: noopen
Surrogate-Control: no-store
Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
When I try to get this header on the client side, I get only some default headers.
function fetchData(path, options) {
return fetch(`${API_URL}${path}`, options)
.then(parseResponse(path));
}
const response = yield call(
fetchData,
url,
requestOptions,
);
console.log(response.headers && Array.from(response.headers))
Did not return "Some-Header"
[
[
"cache-control",
"no-store, no-cache, must-revalidate, proxy-revalidate"
],
[
"content-type",
"application/octet-stream"
],
[
"expires",
"0"
],
[
"pragma",
"no-cache"
]
]
Access-Control-Allow-Headers allows incoming headers. What you send out from the server is always allowed.
As for the response, you will need to add the header and a value server-side.
I used the wrong header. I should use the Access-Control-Expose-Headers header.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers
I want to share a user consent state on multiple domains. I tried to do it by sending multiple fetch requests, that contain the value as body. Each handler should simply accept the request and store the body as cookie-value.
Client-Side:
fetch(data.handler, {
method: 'POST',
mode: 'cors',
cache: 'no-cache',
credentials: 'include',
headers: {
'Content-Type': 'text/plain', // if we use application/json, a OPTIONS request (preflight) will be sent, that causes problems
},
redirect: 'follow',
body: JSON.stringify(cookieValue),
}).then(response => {
if (response.ok) {
resolve();
} else {
reject();
}
})
On the server side i send a response with a Set-Cookie Header
This is my response for the CORS domain:
curl 'http://localhost-domain2:8000/handler' -v -X POST \
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0' \
-H 'Accept: */*' \
-H 'Accept-Language: de,en;q=0.7,en-US;q=0.3' \
-H 'Accept-Encoding: gzip, deflate' \
-H 'Referer: http://localhost-domain1:8000/' \
-H 'Content-Type: text/plain' \
-H 'Origin: http://localhost-domain:8000' \
-H 'Connection: keep-alive' \
-H 'Pragma: no-cache' \
-H 'Cache-Control: no-cache' \
--data-raw '{"my":"values"}'
* Trying 127.0.0.1:8000...
* TCP_NODELAY set
* Connected to localhost-domain2 (127.0.0.1) port 8000 (#0)
> POST /handler HTTP/1.1
> Host: localhost-domain2:8000
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0
> Accept: */*
> Accept-Language: de,en;q=0.7,en-US;q=0.3
> Accept-Encoding: gzip, deflate
> Referer: http://localhost-domain1:8000/
> Content-Type: text/plain
> Origin: http://localhost-domain1:8000
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-cache
> Content-Length: 145
>
* upload completely sent off: 145 out of 145 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.17.8
< Date: Tue, 02 Aug 2022 10:14:49 GMT
< Content-Type: application/json; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: gdpr=%7B%22my%22%3A%22values%22%7D; expires=Wed, 02 Aug 2023 10:14:49 GMT; path=/; samesite=lax
< Access-Control-Allow-Origin: http://localhost-domain1:8000
< Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type,Set-Cookie
< Content-Encoding: gzip
I masked some things like the json or the domain names, so some content-lengths will be wrong, but this is the actual response
The request is sent, the server does what it should but the Set-Cookie is not processed, neither by chrome, nor by firefox. If i visit localhost-domain2:8000 no cookie exists.
So - what combination of fetch-parameters, HTTP Headers and Cookie-Parameters are required to make the client store the cookie for the other domain?
Edit: Just to clarify: I know i cant share cookies directly and i dont want to, i simply want the cookie to exist for the other domain, just like a single-sign-on
Update
Changing everything to ssl and using "None" for the sameSite Attribute does not change anything. Using Strict wont work neither.
Update 2
Opening the network request to the second domain from the dev-tools in a new window results in the cookie being correctly set, so its indeed the fetch api, that i have problems with.
UPDATE
Okay, i was curious - it also works with fetch if i do everything else exactly the same as described below.
Setting of the Cookie exactly the same on client and server
Use the following fetch request
fetch(url, {
mode: "cors",
credentials: "include",
method: "get",
cache: "no-cache",
redirect: "follow",
})
The rest (Server-side, headers) like described below.
Firefox with cookie-protection still not working...
ORIGINAL ANSWER
The following configuration works:
Insteadof using fetch to send a post request, i create an iframe with the src being set to the handler. The cookie-value is added as url parameter
To resolve the promise i use iframe.onload and iframe.onerror
The Cookie ist set identically in the client and on the server.
javascript example:
const secure = window.location.protocol.indexOf('https') > -1;
const sameSite = secure ? 'none' : 'lax';
// so in vanillaJs
document.cookie = 'key=value;' + (secure ? '; secure' : '') + '; sameSite=' + sameSite;
The domain field is kept empty for both sides (client, server) and the path is set to '/' in both cases, secure and sameSite are set the same way as on the client...
The HTTP Response from the Server contains the following headers (besides Set-Cookie)
Access-Control-Allow-Origin: ${HTTP_ORIGIN:-localhost-domain1}
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Cache-Control: no-cache, must-revalidate, no-store
Content-Type: text/html
pragma: no-cache
expires: 0
And an empty html5 document to avoid console errors
I dont know what really caused the issue, but this is how it works for the moment.
Firefox
This wont work in latest Firefox versions if Cookie Protection is enabled! It did not prompt me to allow the cookie usage, it just blocked it.
Edit: And it only seems to work via https
I'm trying to fetch data from my Jira Cloud instance through the Jira and Jira Agile REST APIs using JavaScript in a browser. Queries to Jira REST API work fine but identical queries to Jira Agile REST API keep failing with the response
Response for preflight has invalid HTTP status code 401.
I'm using Basic Authentication with user ID and an API token obtained from Jira. With cURL and ARC, I'm able to successfully retrieve data both from the Jira REST API and the Jira Agile REST API, so the authentication against both APIs seems to work. In JS I have tried with both fetch() and jquery ajax() and the result was the same.
function fetchFromJira(url, id, token) {
const authorizationString = 'Basic ' + btoa(id + ':' + token);
const options = {
method: 'GET',
headers: {
Authorization: authorizationString,
'Content-Type': 'application/json',
},
};
fetch(url, options)
.then(response => {
if (response.ok) {
return response.json();
} else {
throw new Error(response.status);
}
})
.then(json => {
console.log(json);
})
.catch(error => {
console.log(error);
});
}
fetchFromJira(
'https://fredrikastrom.atlassian.net/rest/api/latest/issue/10000',
'<user id>',
'<API token>'
); // successful
fetchFromJira(
'https://fredrikastrom.atlassian.net/rest/agile/1.0/board',
'<user id>',
'<API token>'
); // fails
The output onto the console looks as follows:
test.js:11 OPTIONS https://fredrikastrom.atlassian.net/rest/agile/1.0/board 401 ()
fetchFromJira # test.js:11
(anonymous) # test.js:33
index.html:1 Failed to load https://fredrikastrom.atlassian.net/rest/agile/1.0/board: Response for preflight has invalid HTTP status code 401.
test.js:23 TypeError: Failed to fetch
test.js:20 {expand: "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations", id: "10000", self: "https://fredrikastrom.atlassian.net/rest/api/latest/issue/10000", key: "FAT-1", fields: {…}}
Here are the preflight request and response headers of the successful query to the Jira REST API:
t=3241 [st= 89] HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
--> :authority: fredrikastrom.atlassian.net
:method: OPTIONS
:path: /rest/api/latest/issue/10000
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: sv-SE,sv;q=0.9,en-US;q=0.8,en;q=0.7,fi;q=0.6
access-control-request-headers: authorization,content-type
access-control-request-method: GET
cache-control: no-cache
origin: http://127.0.0.1:8080
pragma: no-cache
referer: http://127.0.0.1:8080/test/index.html
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36
t=3241 [st= 89] -HTTP_TRANSACTION_SEND_REQUEST
t=3241 [st= 89] +HTTP_TRANSACTION_READ_HEADERS [dt=68]
t=3278 [st=126] HTTP2_STREAM_UPDATE_SEND_WINDOW
--> delta = 0
--> stream_id = 1
--> window_size = 65535
t=3309 [st=157] HTTP_TRANSACTION_READ_RESPONSE_HEADERS
--> HTTP/1.1 200
status: 200
server: AtlassianProxy/1.15.8.1
vary: Accept-Encoding
cache-control: no-cache, no-store, no-transform
content-type: text/html;charset=UTF-8
content-encoding: gzip
strict-transport-security: max-age=315360000; includeSubDomains; preload
date: Sat, 12 Oct 2019 06:33:50 GMT
atl-traceid: 519aa518a8e8e5ea
x-arequestid: c68d7b95-3635-49e1-a2fd-971e0502adf5
x-xss-protection: 1; mode=block
timing-allow-origin: *
x-content-type-options: nosniff
set-cookie: atlassian.xsrf.token=7a27221d-39bc-4555-9569-b26a0beb9689_b9e038120f5696c0bac7202f986ee24d3752c6fa_lout; Path=/; Secure
and here are the correspinding headers from the failing request to Jira Agile REST API:
t=5918 [st= 5] HTTP_TRANSACTION_HTTP2_SEND_REQUEST_HEADERS
--> :authority: fredrikastrom.atlassian.net
:method: OPTIONS
:path: /rest/agile/latest/board
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-GB,en-US;q=0.9,en;q=0.8
access-control-request-headers: authorization,content-type
access-control-request-method: GET
origin: http://127.0.0.1:8080
referer: http://127.0.0.1:8080/test/index.html
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.62 Safari/537.36
t=5919 [st= 6] -HTTP_TRANSACTION_SEND_REQUEST
t=5919 [st= 6] +HTTP_TRANSACTION_READ_HEADERS [dt=65]
t=5984 [st=71] HTTP_TRANSACTION_READ_RESPONSE_HEADERS
--> HTTP/1.1 401
status: 401
server: AtlassianProxy/1.15.8.1
vary: Accept
www-authenticate: OAuth realm="https%3A%2F%2Ffredrikastrom.atlassian.net"
cache-control: no-transform
content-type: application/xml;charset=UTF-8
strict-transport-security: max-age=315360000; includeSubDomains; preload
date: Sat, 12 Oct 2019 07:05:10 GMT
atl-traceid: 2caf28fb1cce9a77
x-arequestid: 817e2b89-e3d1-431b-b892-781fc78c9669
x-xss-protection: 1; mode=block
timing-allow-origin: *
x-content-type-options: nosniff
set-cookie: atlassian.xsrf.token=7a27221d-39bc-4555-9569-b26a0beb9689_dafc86c05dbdc472c9b99300b351fe0dd62b305d_lout; Path=/; Secure
content-length: 174
Interestingly, the request headers look slightly different even if the requests are made with the same function where only the requested URLs differ. The succeeding request includes the cache-control and pragma headers, and the accept-language header includes one more language. But none of these should reasonably have any impact on whether the server will accept the preflight request?
Any clue why the one request succeeds and the other one fails?
I'm trying to get the response header of a website and get the cookies that i can find inside. There is no problem, it's working when i start the request through a terminal with "node file.js".
But i'm launching the POST request through a local HTML page, so i used browersify for be able to launch a request from a client-side (or at least this is what i understood).
Then i'm using a CORS proxy to get around “No Access-Control-Allow-Origin header” problems. When i start the request from my local HTML page it's working and i can read the body but i'm not able to find the reponse header of the website and get the cookie that i need.
Here how my request looks like:
function connectionInfoConcert(account, psw, next){
console.log("-------------CREATE HEADER-------------\n")
var options = {
method: 'POST',
url: 'https://tranquil-thicket-71867.herokuapp.com/https://www.infoconcert.com/mon-infoconcert/connexion.html',
headers: {
'Accept':'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8',
'Accept-Language':'fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7',
'Cache-Control':'max-age=0',
'Connection':'keep-alive',
'Content-Length':'184',
'Content-Type':'application/x-www-form-urlencoded',
'origin': 'https://www.infoconcert.com',
'referer': 'https://www.infoconcert.com/mon-infoconcert/connexion.html'
},
form: {
origin:'',
username: account,
password: psw
}
};
console.log("-------------END HEADER-------------\n-----------START REQUEST-----------------------")
request(options, function (error, response, body) {
if (!error) {
console.log(response)
console.log(body)
console.log(response.headers['set-cookie'][0]); //obviously 'set-cookie' doesn't exist
}
else {
console.log(error)
console.log(response)
console.log("-------------ERROR------------")
return console.log("Something went wrong")
}
});}
https://www.infoconcert.com/mon-infoconcert/connexion.html is the website where i try to get the cookie
https://tranquil-thicket-71867.herokuapp.com is the CORS proxy that i'm using.
If some of you know how to be able to get the correct header it would be really nice !
Edit 1 :
The problem is when i do my request to "https://www.infoconcert.com/mon-infoconcert/connexion.html" i can find the cookie that i'm looking for in response.headers["set-cookie"].
But because i'm doing the request from a html page it's not working and i'm doing the request to "https://tranquil-thicket-71867.herokuapp.com/https://www.infoconcert.com/mon-infoconcert/connexion.html" but i can't find my cookie in the response.
Here the header of the response i got from "https://tranquil-thicket-71867.herokuapp.com/https://www.infoconcert.com/mon-infoconcert/connexion.html"
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: server,vary,cache-control,content-type,content-encoding,p3p,date,expires,pragma,connection,x-cache-info,x-final-url,access-control-allow-origin
Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Thu, 03 May 2018 17:23:49 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
P3p: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID CUR ADM DEV OUR BUS"
Pragma: no-cache
Server: Apache
Transfer-Encoding: chunked
Vary: Accept-Encoding,User-Agent
Via: 1.1 vegur
X-Cache-Info: not cacheable; response specified "Cache-Control: private"
X-Cors-Redirect-1: 302 https://www.infoconcert.com/mon-infoconcert/index.html
X-Cors-Redirect-2: 302 https://www.infoconcert.com/mon-infoconcert/connexion.html
X-Final-Url: https://www.infoconcert.com/mon-infoconcert/connexion.html
X-Request-Url: https://www.infoconcert.com/mon-infoconcert/connexion.html
So i think it's my proxy who doesn't forward the cookie that he gets.
If you need more details just ask.
Thanks you very much for your help
I'm developing an Azure MobileService / CordovaApp setup. The server runs locally and has the following setting to enable CORS:
<add name="Access-Control-Allow-Origin" value="*" />
The api can be called via browser using addresses like
http://localhost:59477/api/item/explore/A/B
The client script that's trying to depict this call is the following:
var client = new WindowsAzure.MobileServiceClient('http://localhost:59477/', 'http://localhost:59477/', '');
GetItems.addEventListener("click",
function ()
{
client.invokeApi("item/explore/A/B",
{
method: "get"
})
.done(
function (results)
{
alert(results.result.count);
},
function (error)
{
var xhr = error.request;
alert('Error - status code: ' + xhr.status + '; body: ' + xhr.responseText);
alert(error.message);
}
);
}
);
What I get is status 405 - Method not allowed, which I don't understand for two reasons:
The invoked Service Action is decorated with the [HttpGet] Attribute
The response headers seem to say GET is fine:
HTTP/1.1 405 Method Not Allowed
Allow: GET
Content-Length: 76
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/8.0
X-SourceFiles: =?UTF-8?B?RjpcQ29kZVxGb290UHJpbnRzXGZvb3RwcmludHMuU2VydmVyXEZvb3RwcmludHNTZXJ2aWNlXGFwaVxmb290cHJpbnRcZXhwbG9yZVw1MS4yNzcwMjJcNy4wNDA3ODM=?=
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Date: Sat, 15 Aug 2015 18:08:30 GMT
Any idea what I can do to get this running?
Edit
The Raw request shows that, as already expected by Jeremy Foster, the client sends a request of the type OPTIONS:
OPTIONS http://localhost:59477/api/fp/get?id=1 HTTP/1.1
Host: localhost:59477
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost:4400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36
Access-Control-Request-Headers: accept, x-zumo-features, x-zumo-installation-id, x-zumo-version
Accept: */*
Referer: http://localhost:4400/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
I managed to support this request applying the [HttpOptions] attribute to my action method. Now I get a more or less valid response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/8.0
X-SourceFiles: =?UTF-8?B?RjpcQ29kZVxGb290UHJpbnRzXGZvb3RwcmludHMuU2VydmVyXEZvb3RwcmludHNTZXJ2aWNlXGFwaVxmcFxnZXRcMQ==?=
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Date: Sun, 23 Aug 2015 19:34:21 GMT
Content-Length: 234
...
At least that's what fiddler tells me. The AzureMobileServiceClient throws yet another issue, which roughly translates as:
Cross-Origin request blocked, missing token 'x-zumo-installation-id' in CORS header row 'Access-Control-Allow-Headers' on CORS-Preflight-Channel
Turn on Fiddler and try your api call from the browser and then again using the Mobile Services client and compare your raw HTTP requests to see what's different.
Try to run through the CORS Support section of this blog post: http://azure.microsoft.com/blog/2014/07/28/azure-mobile-services-net-updates/.
A side note: The x-zumo-installation-id error you were getting was because the client requested access for a list of headers (see the Access-Control-Request-Headers in your request) and the server did not return that same list in the Access-Control-Allow-Headers header. Using the MS_CrossDomainOrigins setting as mentioned in the above blog post takes care of this by setting the allowed headers to * (all) by default.