I am performing a fetch:
fetch(url, fetchOptions);
fetchOptions is configured like so:
var fetchOptions = {
method: options.method,
headers: getHeaders(),
mode: 'no-cors',
cache: 'no-cache',
};
function getHeaders() {
var headers = new Headers(); // Headers is part of the fetch API.
headers.append('User-ID', 'foo');
return headers;
}
Checking fetchOptions at runtime it looks as follows:
fetchOptions.headers.keys().next() // Object {done: false, value: "user-id"}
fetchOptions.headers.values().next() // Object {done: false, value: "foo"}
But user-id is nowhere to be found in the request headers per Chrome dev tools:
GET /whatever?a=long_name&searchTerm=g HTTP/1.1
Host: host:8787
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
accept: application/json
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Referer: http://localhost:23900/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,fr;q=0.6
Why can I not see my "User-ID" header in Chrome dev tools, and why does the header key appear to have been lowercased?
Incase someone else has a similar problem there were two possible culprits for this:
I might not have been starting Chrome with the correct flags.
The following didn't work when run from a Windows shortcut:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -enable-precise-memory-info -disable-web-security
The following did work when run from a Windows command prompt:
C:\whatever\48.0.2564.82\application\chrome.exe --disable-web-security --user-data-dir=C:\whatever\tmp\chrome
The addition of no-cors to the mode of the request might have caused an OPTIONS request to precede the GET request and the server did not support OPTIONS.
Related
I'm tring to add a header called "access-token" to all my http request like this:
var app= angular.module("MainModule", ["ngRoute"]);
app.run(function($http){
$http.defaults.headers.common['access-token'] =ACCESSTOKEN;
})
and in my service:
service.get= function (x) {
console.log(ACCESSTOKEN)
return $http({
method: "GET",
headers: {
'Content-Type': 'application/json',
'access-token': ACCESSTOKEN
},
crossDomain: true,
url: GETSERVICE.replace("{id}", x),
dataType: 'json'
}).then(function (response) {
if (response.data) {
return response.data;
} else {
return $q.reject(response.data);
}
}, function (response) {
return $q.reject(response.data);
});
}
the problem is that i can't see the header in the network. There is only the OPTION request without my header.
my Back end cors configuration is like:
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Methods", "GET, POST, PUT, PATCH, DELETE, UPDATE, OPTIONS");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, access-token");
chain.doFilter(req, res);
Any ideas how to fix it?
TY
EDIT 1:
Here is the OPTION request without modifiy headers
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7
Access-Control-Request-Headers: access-token
Access-Control-Request-Method: GET
Cache-Control: no-cache
Connection: keep-alive
Host: localhost:8081
Origin: http://localhost:9080
Pragma: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
and whit modify headers (worked):
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7
Access-Control-Request-Headers: access-token
Access-Control-Request-Method: GET
access-token: 1520963789861
Cache-Control: no-cache
Connection: keep-alive
Host: localhost:8081
Origin: http://localhost:9080
Pragma: no-cache
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
whit modify headers I have the token in the request
CORS exists to secure APIs so that random clients do not make calls to them.
JavaScript has to take permissions to be able to make calls to those APIs. Browser is supposed to do all the heavy lifting related to CORS. But the only requirement is that the server should return the following HTTP headers for an OPTIONS request from a client:
Access-Control-Allow-Origin: <Origin fetched from the request>
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, DELETE
Access-Control-Allow-Headers: <ACCESS-CONTROL-REQUEST-HEADERS fetched from request>
If that is NOT an option, then on the client side, following code can be added to prevent all OPTIONS requests, which compromises security:
app.config(['$httpProvider', function ($httpProvider) {
$httpProvider.defaults.headers.common = {};
$httpProvider.defaults.headers.post = {};
$httpProvider.defaults.headers.put = {};
$httpProvider.defaults.headers.patch = {};
$httpProvider.defaults.headers.get = {};
}]);
See: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
That OPTIONS request is called "preflight request". It only checks if your client has a right to send a request at all (when a server has a configured CORS). If server responds positively then your browser automatically send a full request with all you provided headers.
$httpProvider or $http module:
//with the provider, in the app.config():
$httpProvider.defaults.headers.post['Content-Type'] = 'application/json; charset=utf-8';
$http.defaults.headers.common['Content-Type'] = 'application/json; charset=utf-8';
Ok I will tell you what were the problem.
The genial man who write the rest api that I call in cross domain checked the value of the token also in the OPTION request going in null pointer.
Solved adding a filter for the option request.
TY for all
I'm trying to make a dojo xhrGet request using basic authentication but I keep getting 403 forbidden error. I can make the request with curl from the command line, so I know my credentials are valid. When I check the request headers, the Authorization: Basic header isn't even being set. What am I doing wrong:
var lookupArgs = {
url: "https://myendpoint.com/myapi/endpoint",
user:"myemail#myendpoint.com",
password:"mypassword",
handleAs: "text",
load: function(data) {
content_node.innerHTML = data;
},
error: function(error) {
content_node.innerHTML = error;
}
}
dojo.xhrGet(lookupArgs);
Request Header:
GET /myapi/endpoint HTTP/1.1
Host: myendpoint.com
Connection: keep-alive
Origin: http://my-origin
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3315.3 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: */*
Referer: http://my-origin
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
In angularjs i must set a custom header for a POST
So i make:
var config = { 'Content-Type': 'application/x-www-form-urlencoded', 'TenantCode': 'MYTENANT', 'LoginType': 'PASSW' };
So i execute the post
$http.post(urlBase + '/Token', data, config)
Anyway when i inspect the request i have
OPTIONS /Token HTTP/1.1
Host: test.strokein.it
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost:54599
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,like Gecko) Chrome/46.0.2490.86 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://localhost:54599/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: it-IT,it;q=0.8,en-US;q=0.6,en;q=0.4
and i don't see my header parameter
Why? What's the problem?
I think your config needs to look something like this:
var config = {
headers : {
'Content-Type': 'application/x-www-form-urlencoded',
'TenantCode': 'MYTENANT',
'LoginType': 'PASSW'
}
};
Looking at this specification of config.
That is your preflight request.
You have a CORS problem because you are testing from localhost to test.strokein.it
Easy fix would be you upload your test script to your server.
But in general, browser will send one more request after it gets an OK CORS response from your server i.e.
'Access-Control-Allow-Origin' : '*'
'Access-Control-Allow-Methods': 'GET, OPTIONS, PUT'
'Access-Control-Allow-Headers': 'Content-Type'
Then you should see your custom headers along with data on that POST request.
Read more here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
I am using Visual Studio 2013 ASP.NET Identity template.
After user successfully logs in, the user is taken to a page with table.
Page has search options and search function is javascript driven
The javascript sends user selected parameters in form of an ajax request
I am having problems because AJAX request is well constructed from client side and sent to correct URL but it immediately gets redirected and parameters are lost.
I am not sure if this is happening because the request should be authenticated/authorized. I tried the following
$.ajax({
type: 'POST',
url: '<%=Config.VirtualDir %>listings.aspx' + '?filterattribute=y&call=ajax',
data: { 'zipcode': ZipCode, 'bedrooms': BedRooms, 'bathrooms': Bathroom, 'SquareFeetMin': SquareFeetMin, 'SquareFeetMax': SquareFeetMax, 'PriceMin': MinPrice, 'PriceMax': MaxPrice, 'Radius': Radius, 'Years': Years, 'IntRate': IntRate, 'DownPayment': DownPayment, 'sort': ddlsort, 'crfrom': capfrom, 'crto': capto, 'cffrom': cflowfrom, 'cfto': cflowto, 'roifrom': roifrom, 'roito': roito, 'vefrom': vefrom, 'veto': veto, 'chksupp': supp, 'undadd': undadd },
beforeSend: function(xhr){
xhr.withCredentials = true;
},
success: function (response) {
$('#DivRender').html(response);
DisplayPaging();
UpdateDropDowns();
$.hideprogress();
}
});
I checked how the request is handled in Fiddler and Here is what happens
Request1
POST /listings.aspx?filterattribute=y&call=ajax HTTP/1.1
Host: localhost:1794
Connection: keep-alive
Content-Length: 277
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8,sv;q=0.6
Cookie: 83VLqQgggt8=CfDJ8EqbzpbyFkFAtEyP1X9rGYWcW8ryXAnh-VbYXDpLXBhNXU5Brq_PAiggJHvIwAXK2yZZPz5_NBCSTjV9FYC1O6PEvmGVe9r8feB74Rjc0hANEjsG_Pf6k6iwYdnRRxxHDD5qSRAAYJHGa3LpH4MOlww; .AspNet.Microsoft.AspNet.Identity.Application=CfDJ8EqbzpbyFkFAtEyP1X9rGYUDNW-ipW7_DjFWLk0XMejiHWRdCnQmZMipzvTZJcnYL3ncfpETFYsVA3s2UHEnvkUJEbxPIBfuNNoRLQrhaoJaegw78lGv1XWRXgJ9g5GikhXprPsC9Nt8n7Wt6UVT24Wao-CHiVHVZVOX3weXu8Eu48W8gEhnXzvG1Vx57tGWPiSbu9mJiIOXoJyO-ybxNuontF7g6hfCAi0f9ohonq2Mal9xWhVtHWUQnIYTdlrbnueX6guTMyCPmS8augNyZSAmGqRfCr9KfoTYy4bAjIaOpxKANS6qeTQdCP07oB_axsNJ1QS1RsxWIj5EHFeENARKK2GEcnKL_mZyRzsvzTWJooyc6b0EfsEOOG48qJiohxQUu8CL_Ag0WdLIvyOyg_6-mFjHEHLatYqRXs_UQgsM0bYABG98p-UlgADehXJ8MyjRDpvT_0K20VnLJPFKUY0bbmBDsg5U34cMBsTfz4qndFr4jsjQDuXlRPCXroyFkHqsefajLHHtW4A5iwniKjNExd_MS9yQZfsXg3DDAPqzg2ZCaFTvrPwMbwyMG6Z5INW0RdShtbtRc_GYWruu0WOQpzcjcfhOZv6x5SLgFGlEYxImME6He1rfZmcAjxb28mmOZWmTRjtE5eqEmAQkGGI; QeabOx42yKQ=CfDJ8EqbzpbyFkFAtEyP1X9rGYUuSJv5TYKtxst2zuRG2lWOmZp_VfHjxfZaE_bUCEWq2rteZo2wx91WWM0BLDhC-RS_LeSjhlbsCNd_Xa-eaQtKHCg6kt0fov8WuunyJBTisOKqkyoEk9a0eBKp8yDptK0; ai_user=18AE4C91-FECF-494B-B67A-486D1A2F5164|2015-08-25T03:19:36.296Z; __AntiXsrfToken=b7689c9fd71643389b3ab3c2e5543f3c; .AspNet.ApplicationCookie=dMOEe4RBWpIuwm_zyjhPKFhEsS2cMLLybv6DeO0-aDn4oo_jTyQq6WzPSmF-GZZa7SDjfs9HSnlWcQyQgP0G9LE_DK9ZPbzeb2tcsu3GNnPkP1LGJz8wmL8JLRh_T4s-o-ZNCnFtbESkQYrQlIX3vBc2FZ0-Kh4dz6T0pGldEQHWXkkTQlUxIlnP5Z224VRL_E9UpbjWBbBxuLXGyAq6IXBiBsK-6q5jhw58FsYp4VnIGp3qM4mdG7lWYP_NcYDt4Z0fMW34p0VaWPImef2CsrLMiBODWDhm-0ogS9fkGpa0_lQHE-H3nvcSUN6cpmqSDA7lZ7EzZjQRsv-09SttMouf9mf3qwaRbjcoxxOez_pzcAypDgkFjnPbdtyDK-9MXyIRajT8pay9mRc-YlpjoZgwW3Ww3de1a4qeRJB7zLNr2Ec8gGVZEFRakUIfIj-RSn4a9vmhETk5UTE8X-Yc99AMDnauKhmg5y09GwhGdO1Iv62kauaD_Kpxq14ATfCu; .ASPXAUTH=1647B3E8FA3AB2D87B584B214BF8BFEB3390BBBE6BBB9F35B6C01A8E2DDB4D3A31A2F1906E93298C87D5FE9A6E1D869D055A1CC2BE6B1A25316B1BEA229E144D2D1FAB1B038013DD96DE9BA072C6511A10526A34DC959868C808FCD458ADDF40DAB7856C3639D74AC00AFD21166D6ED5DF82726E
zipcode=92801%2C92802%2C92804%2C92805%2C92806%2C92807
Response 1: HTTP/1.1 301 Moved Permanently
**Second Immediate Request**
GET /listings?filterattribute=y&call=ajax HTTP/1.1
Host: localhost:1794
Connection: keep-alive
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,sv;q=0.6
Cookie: 83VLqQgggt8=CfDJ8EqbzpbyFkFAtEyP1X9rGYWcW8ryXAnh-VbYXDpLXBhNXU5Brq_PAiggJHvIwAXK2yZZPz5_NBCSTjV9FYC1O6PEvmGVe9r8feB74Rjc0hANEjsG_Pf6k6iwYdnRRxxHDD5qSRAAYJHGa3LpH4MOlww; .AspNet.Microsoft.AspNet.Identity.Application=CfDJ8EqbzpbyFkFAtEyP1X9rGYUDNW-ipW7_DjFWLk0XMejiHWRdCnQmZMipzvTZJcnYL3ncfpETFYsVA3s2UHEnvkUJEbxPIBfuNNoRLQrhaoJaegw78lGv1XWRXgJ9g5GikhXprPsC9Nt8n7Wt6UVT24Wao-CHiVHVZVOX3weXu8Eu48W8gEhnXzvG1Vx57tGWPiSbu9mJiIOXoJyO-ybxNuontF7g6hfCAi0f9ohonq2Mal9xWhVtHWUQnIYTdlrbnueX6guTMyCPmS8augNyZSAmGqRfCr9KfoTYy4bAjIaOpxKANS6qeTQdCP07oB_axsNJ1QS1RsxWIj5EHFeENARKK2GEcnKL_mZyRzsvzTWJooyc6b0EfsEOOG48qJiohxQUu8CL_Ag0WdLIvyOyg_6-mFjHEHLatYqRXs_UQgsM0bYABG98p-UlgADehXJ8MyjRDpvT_0K20VnLJPFKUY0bbmBDsg5U34cMBsTfz4qndFr4jsjQDuXlRPCXroyFkHqsefajLHHtW4A5iwniKjNExd_MS9yQZfsXg3DDAPqzg2ZCaFTvrPwMbwyMG6Z5INW0RdShtbtRc_GYWruu0WOQpzcjcfhOZv6x5SLgFGlEYxImME6He1rfZmcAjxb28mmOZWmTRjtE5eqEmAQkGGI; QeabOx42yKQ=CfDJ8EqbzpbyFkFAtEyP1X9rGYUuSJv5TYKtxst2zuRG2lWOmZp_VfHjxfZaE_bUCEWq2rteZo2wx91WWM0BLDhC-RS_LeSjhlbsCNd_Xa-eaQtKHCg6kt0fov8WuunyJBTisOKqkyoEk9a0eBKp8yDptK0; ai_user=18AE4C91-FECF-494B-B67A-486D1A2F5164|2015-08-25T03:19:36.296Z; __AntiXsrfToken=b7689c9fd71643389b3ab3c2e5543f3c; .AspNet.ApplicationCookie=dMOEe4RBWpIuwm_zyjhPKFhEsS2cMLLybv6DeO0-aDn4oo_jTyQq6WzPSmF-GZZa7SDjfs9HSnlWcQyQgP0G9LE_DK9ZPbzeb2tcsu3GNnPkP1LGJz8wmL8JLRh_T4s-o-ZNCnFtbESkQYrQlIX3vBc2FZ0-Kh4dz6T0pGldEQHWXkkTQlUxIlnP5Z224VRL_E9UpbjWBbBxuLXGyAq6IXBiBsK-6q5jhw58FsYp4VnIGp3qM4mdG7lWYP_NcYDt4Z0fMW34p0VaWPImef2CsrLMiBODWDhm-0ogS9fkGpa0_lQHE-H3nvcSUN6cpmqSDA7lZ7EzZjQRsv-09SttMouf9mf3qwaRbjcoxxOez_pzcAypDgkFjnPbdtyDK-9MXyIRajT8pay9mRc-YlpjoZgwW3Ww3de1a4qeRJB7zLNr2Ec8gGVZEFRakUIfIj-RSn4a9vmhETk5UTE8X-Yc99AMDnauKhmg5y09GwhGdO1Iv62kauaD_Kpxq14ATfCu; .ASPXAUTH=1647B3E8FA3AB2D87B584B214BF8BFEB3390BBBE6BBB9F35B6C01A8E2DDB4D3A31A2F1906E93298C87D5FE9A6E1D869D055A1CC2BE6B1A25316B1BEA229E144D2D1FAB1B038013DD96DE9BA072C6511A10526A34DC959868C808FCD458ADDF40DAB7856C3639D74AC00AFD21166D6ED5DF82726E
How do i make sure that the ajax post request sends session cookies along with the request so that redirect doesnt happen.
If you want to make sure you're not being affected by authentication redirects:
Check out your OWIN Startup class, you should have a line like this (taken from default MVC, will be similar for Web API):
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
});
The LoginPath property here will redirect all unauthenticated requests (if the request requires authorization) to the specified path.
Try your AJAX request again without that LoginPath, you will probably get a 401 Unauthorized.
If you want to keep the LoginPath redirect but don't want it to affect your AJAX calls, check out this post from Brock Allen about handling 401s differently depending on the requesting application.
In your case it is better to use [WebMethod] instead of sending a request to the page. In WebMethod also you can access Session.
I've been stuck at this for a while now. I have ajax request here:
$.ajax({
url: UPDATE_USER_INFO_URL ,
type: "POST",
dataType: "json",
contentType: "application/json",
data: JSON.stringify({user:'user'}),
success: function (data, textStatus) {
if(data["statusCode"] && data["statusCode"] == 1) {
_callback(1,data);
}
else {
_callback(0,data);
}
},
error: function (jqXHR, textStatus){
_callback(0, {});
}
});
If I set UPDATE_USER_INFO_URL to a specific URL, fiddler show nothing in the body. If I set UPDATE_USER_INFO_URL to something else (even invalid URL), it does put {user:'user'} in the body in fiddler.
With original UPDATE_USER_INFO_URL:
POST http://10.35.50.26:8080/SelfServiceWs/user/session/upduserinfo HTTP/1.1
Accept: application/json, text/javascript, ; q=0.01
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Referer: http://10.35.50.26:8080/SelfService/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: 10.35.50.26:8080
Connection: Keep-Alive
Pragma: no-cache
Cookie: JSESSIONID=0BF9D9CCCE9030E60AB0BCE5F6562CD8
Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==
Content-Length: 0
Chage url to /SelfServiceWs/abcdef
POST http://10.35.50.26:8080/SelfServiceWs/abcdef HTTP/1.1
Accept: application/json, text/javascript; q=0.01
Content-Type: application/json
X-Requested-With: XMLHttpRequest
Referer: http://10.35.50.26:8080/SelfService/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: 10.35.50.26:8080
Content-Length: 15
Connection: Keep-Alive
Pragma: no-cache
Cookie: JSESSIONID=9E79779805579A7964E03AAD76DF043B
{"user":"user"}
I have many other ajax calls, all are working as expected.
It must be little thing that I am missing.
I figured this out.
I have an authentication servlet filter to url /user/ssoauth, unexpectedly (to me), it made eveything call to URL under /user path (including /user/session/upduserinfo) to send out Authorization header. Moved filter to /user/auth/ssoauth stop client to send authorization header when calling user/session/upduserinfo and fix the problem.
<filter-mapping>
<filter-name>SecurityFilter</filter-name>
<url-pattern>/user/ssoauth</url-pattern>
</filter-mapping>
cause every client call to URL after /user to send Authorization header.
I learned something new today!
try this
data: JSON.stringify({'user':'user'}),