I'm sending POST data with AJAX:
const form = d.getElementById('form');
form.addEventListener('submit', SendData);
function SendData(e) {
e.preventDefault();
var data = e.target.getElementsByTagName('input')[0].value.trim();
var xhr = new XMLHttpRequest();
xhr.addEventListener('load', function(event){
console.log(event.target.responseText);
});
xhr.addEventListener('error', function(event){
console.log(event.target.statusText);
});
xhr.open('POST', '/db', true);
xhr.send('data=' + data);
}
But when I use IE11, server receives data only once in every two requests:
1:
POST http://localhost:99/db HTTP/1.1
Accept: */*
Referer: http://localhost:99/
Accept-Language: ru
Content-Type: text/plain;charset=UTF-8
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like
Gecko
Host: localhost:99
Content-Length: 13
Connection: Keep-Alive
Cache-Control: no-cache
data=01234567
2:
POST http://localhost:99/db HTTP/1.1
Accept: */*
Referer: http://localhost:99/
Accept-Language: ru
Content-Type: text/plain;charset=UTF-8
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like
Gecko
Host: localhost:99
Content-Length: 13
Connection: Keep-Alive
Cache-Control: no-cache
I noticed, when I use Fiddler for debugging, server receives data every time. Couldn't anybody explain to me this behavior, and how to fix it?
Did you try to use jQuery ajax functionality? This has the advantage that it is working across browsers flawlessly, and needs only one syntax. I know, that most people do not like to use additional frameworks, but this one simplifies coding a lot.
e.g.:
$.ajax({
url:'https://my.server.com/myscript.php,
type:'post',
data: {
var1: "x",
var2: "y",
},
success: function(data) {
// here goes the data, returned from your php script e.g.
}
});
Related
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
I'm making a POST request from a Chrome extension that appears identical to the one that submitting the form manually would do. I've submitted both and compared the body and headers and they seem to be identical.
The POST made via the browser form results in a 302 redirect. The POSTed entry is created and the user ends up on an edit screen for it.
The POST made via the extension results in a 500 error.
I'm filtering many of the headers sent by the extension to match those made by the browser, in case the server is looking for certain things that tip off a request as being non-native.
Hoping to exhaust all options before contacting the devs of the system being POSTed to. Any obvious things that could be happening server-side to block this request?
Here's the POST request made via the browser form:
Request Headers
Host: myhost.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 901
Referer: https://myhost.com/referer
Cookie: app2=cookieredacted
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
Request Body
record[user_name]=aasldkjflasdjf
record[new_password]=ljl;jl;kjklj
record[first_name]=ethan
record[middle_name]
record[last_name]=lastnm
record[name_suffix]
record[gender]=M
record[dob]=07/28/77
record[ssn]=654656546
record[group_number]
record[misc_number]
record[mothers_maiden_name]
record[active]=N
record[active]=Y
record[has_paper_chart]=0
record[notes]
record[address1]=234+htha+st
record[address2]
record[city]=euge
record[county_of_residence]
record[state]=OR
record[zip]=98754
record[country]
record[tel1]=5155555555
record[tel1_status]=4
record[tel2]
record[tel2_status]
record[cell]
record[cell_status]
record[email]=ethan#foo.com
record[preferred_contact]=home_tel
record[house]
record[room]
record[bed]
record[classroom]
Response Headers
Server: nginx/1.6.2
Date: Sun, 09 Jul 2017 01:06:12 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
Status: 302 Found
Location: /entry/edit
And from the extension:
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.5
Cache-Control:no-cache
Connection:keep-alive
Content-Length:920
Content-Type:application/x-www-form-urlencoded
Cookie:app2=cookieredacted; gsScrollPos-2545=
Host:myhost.com
Pragma:no-cache
Referer:https://myhost.com/referer
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.50 Safari/537.36
Request Body
new_password_stub:"FoECbiRN"
record[active]:"Y"
record[address1]:"123 N 5th St"
record[address2]:""
record[bed]:""
record[cell]:""
record[cell_status]:""
record[city]:"Eugene"
record[classroom]:""
record[country]:""
record[county_of_residence]:""
record[dob]:"9/28/91"
record[email]:"ethan#foo.com"
record[first_name]:"Foo"
record[gender]:"M"
record[group_number]:""
record[has_paper_chart]:0
record[house]:""
record[last_name]:"Bar"
record[middle_name]:""
record[misc_number]:""
record[mothers_maiden_name]:""
record[name_suffix]:""
record[new_password]:"FoECbiRN"
record[notes]:""
record[preferred_contact]:"home_tel"
record[room]:""
record[send_notifications]:0
record[ssn]:"222222222"
record[state]:"OR"
record[tel1]:"5155555555"
record[tel1_status]:2
record[tel2]:""
record[tel2_status]:""
record[user_name]:"BarFoo2017"
record[zip]:"97401"
Response Headers
Cache-Control:no-cache
Connection:keep-alive
Content-Length:5110
Content-Type:text/html; charset=utf-8
Date:Sun, 09 Jul 2017 02:09:33 GMT
Server:nginx/1.6.2
Set-Cookie:mysite_session_id=; max-age=0; expires=Thu, 01 Jan 1970 00:00:00 -0000
Status:500 Internal Server Error
Thanks to wOxxOm for this one -
The extension was posting an extra field record[send_notifications] which was causing the 500 error.
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.
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'}),