I've got a problem with an Ajax request in my web project. Most of the time it works just fine but sometimes there is simply no request from the client (it does not show in wireshark), FireBug just shows the request marked red.
Project looks like the following:
Java Backend with JSPs, Client is using the Firefox Browser
The request is done via prototypejs using the Ajax Updater function. I can debug the request preparation via firebug until the Ajax Update function fires the request but then no request is listed in my wireshark output (although all other request are listed just fine).
So I have a (sometimes) vanished Ajax request with no error and no clue where to look :( Any help would be much appreciated.
Request:
[...]/ajax/gruppe/loadTreeList.do?ajax=true&tstamp=645&context=GRUPPE&level=0&itemid=0
RequestHeader:
Accept text/javascript, text/html, application/xml, text/xml, /
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Cookie JSESSIONID=326D8AEAAFD254760CEC8D050734807E
Host localhost:8080
Referer [...]/domain/druck/gruppe.do
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0
X-Prototype-Version 1.7.1
X-Requested-With XMLHttpRequest
There is no response.
Related
I send a POST Ajax request to a Laravel Controller but I get a 302 Found response code.
The controller is the ForgotPasswordController provided by Laravel's Auth package, so nothing special about it.
It has the guest middleware in its constructor and I found that if I remove this middleware from the constructor, the Ajax request works correctly (it returns a 200 response code).
The Ajax request has the X-CSRF-TOKEN and X-XSRF-TOKEN headers, so I don't think there is something missing.
I'm sending this Ajax request from a VueJS password reset form with the Axios library.
Why my POST request does not work if the controller has the guest middleware ?
Here are the headers sent with the request :
POST /password/email HTTP/1.1
Host: myapp.dev
Connection: keep-alive
Content-Length: 37
Pragma: no-cache
Cache-Control: no-cache
Origin: http://myapp.dev
X-XSRF-TOKEN: eyJpdiI6IjRqTk1yTXFsXC9FVlRzckF0dUM4azdRPT0iLCJ2YWx1ZSI6IjY0MUZzaEpCTXJDcUhzUGhcL2dzYVJmalQrR3pwV3IzYWxiTSt4dVwvN2VVKzJ4b2t3XC9GcVhJcllmK3pQYVV4VGFIZG4wZ0s3NlNCTG01WEl6YzBCY2NRPT0iLCJtYWMiOiIwYmNjOTRiZGJjZTM2YjYyMWJiMzRhNTlkOTkwOWU4Y2M4NmYzYzI5NjhiMTU4MDdiMGJkMmJhYmMwODEzMDhjIn0=
X-CSRF-TOKEN: nejsetydvFWgeqppZc5XQtX04b5AdXlsTKSgaydj
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Content-Type: application/json;charset=UTF-8
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
Referer: http://myapp.dev/password
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: XSRF-TOKEN=eyJpdiI6IjRqTk1yTXFsXC9FVlRzckF0dUM4azdRPT0iLCJ2YWx1ZSI6IjY0MUZzaEpCTXJDcUhzUGhcL2dzYVJmalQrR3pwV3IzYWxiTSt4dVwvN2VVKzJ4b2t3XC9GcVhJcllmK3pQYVV4VGFIZG4wZ0s3NlNCTG01WEl6YzBCY2NRPT0iLCJtYWMiOiIwYmNjOTRiZGJjZTM2YjYyMWJiMzRhNTlkOTkwOWU4Y2M4NmYzYzI5NjhiMTU4MDdiMGJkMmJhYmMwODEzMDhjIn0%3D; laravel_session=eyJpdiI6IkJnczRHV3NcLzhLbzZWaUlvTTI2cFlBPT0iLCJ2YWx1ZSI6IkpQYytLXC9pQ1R3MTZlaEx2QWJ4bGpSd21BV25jelJKVDJkQVdcL25GSG4rQkpQc1duZHIrTjErOGt3bk5BVVVcL3FTK1c2XC83Y1NqTmxBaVZ1bkQ2TWV5Zz09IiwibWFjIjoiNzg4Y2UyNWQ0ODcxMWNkNWE3MmU4ZDY1MmIyNTE0NDgwMzFmM2ZjYzkxMzM5ZGM5ZTk5MDI4NjE4OGRkNmJjYyJ9
Ok i found... it's just that I was authenticated when doing these requests. So the guest middleware was redirecting me... shame on me !
302 response usually because your request is redirected by laravel. if you expect json response don't forget to add Accept: 'application/json' on your header request then you will see what actually wrong
You have to look closer into your controller. You have to return json. Also take a look in the network console in the browser. If response code is 302 there is a location. So if a location is the login page - validation not passed in the middleware
I'm using a POST request in jmeter as below,
POST https://aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net/signalr/connect
POST data:
clientProtocol=1.5&connectionData=%5B%7B%22name%22%3A%22bulkprocesshub%22%7D%5D&connectionToken=DWGWhf7zGj9TyO4cZn2kqH%2Bennba0V7qyAuAE2wIeu3vIoj%2FrLXemcaBz%2Fto3JjEs%2BaVviiFagxtax8E9PbE36cnBAlrByzw5qBwmIu9glop75vPY3XI0me52yTDiWC%2B9Zoalg%3D%3D&processId=b47fe282-8112-4a11-a18c-7629ac31b816&transport=longPolling
Request Headers:
X-Requested-With: XMLHttpRequest
Accept: text/plain, */*; q=0.01
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Referer: https://aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net/ESS/DataType
Connection: keep-alive
Connection: keep-alive
Host: aumaz-ap-perf-ess-web-2.aumaz-ase-dev002.p.azurewebsites.net
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Length: 315
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
If I use the same POST request in browser i can able to get the exact response. But in jmeter I'm getting the response as Bad request.
As of now, I'm using jmeter 3.01 and I have installed all the certificates needed. Can anyone please give solution for this
The most problem here seems to be that server doesn't respond with any details of what's wrong with the request. Correct?
Then do two things:
1) Install Fiddler, capture what you're sending through browser, and through JMeter, compare.
That may give you a clue what's the difference.
2) Reach server logs and see what's going on, there may be way more intrinsic information on why request was considered invalid.
I have finally got a solution. If I pass those parameters in parameters it doesn't work but i gave all the parameters with & in the path itself.
And used ${__urlencode{parameter}} to encode the parameters which are passing as encoded value and then I didn't face any Bad request issue.
Even now, I don't know how it worked. But finally got a solution by this way.
I'm developing some site aaa.com with django, which sends cross-domain ajax "GET" requests to receive json data from bbb.com which is also running on django and is using REST framework. At this point everything works pretty fine with adding crossDomain: true; withCredentials:true. And of course its configurated on server-side of aaa.com.
...-Allow-Credentials: true;
...-Allow-Origin: bbb.com
The main issue comes when aaa.com is trying to make PUT POST DELETE ajax requests.
According to CORS documentation:
[https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0], client side ajax request is correct, and
...-Allow-Headers, ...-Allow-Methods
is matched with
...-Request-Headers, ...-Request-Methods
so this request is not 'simple' and first of all browser sends preflight request from aaa.com to bbb.com to ask if some custom headers and methods are allowed.
Everything is OK But I'm still getting 403 Error. Here is the request/response:
General:
Request URL:http://bbb.com/api/someapipage/
Request Method:OPTIONS
Status Code:403 Forbidden
Remote Address:some ip:80
Response Headers:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:accept, content-type, x-csrftoken, x-requested-with
Access-Control-Allow-Methods:GET, POST, OPTIONS, HEAD, PUT, DELETE
Access-Control-Allow-Origin:http://aaa.com
Allow:GET, POST, HEAD, OPTIONS
Connection:Keep-Alive
Content-Language:en
Content-Type:application/json
Date:Mon, 04 Jul 2016 14:20:38 GMT
Keep-Alive:timeout=5, max=100
Server:gunicorn/19.6.0
Transfer-Encoding:chunked
Vary:Accept,Accept-Language,Cookie
X-Frame-Options:SAMEORIGIN
Request Headers:
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,ru;q=0.6
Access-Control-Request-Headers:accept, content-type, x-csrftoken
Access-Control-Request-Method:POST
Connection:keep-alive
Host:aaa.com
Origin:http://aaa.com
Referer:http://aaa.com/
User-Agent:Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
After week of tries to fix this issue I realised that server wants to Vary: Cookie on pre-flighted request which is impossible because cross-domain pre-flight request cannot contain cookie in its header.
I started finding some solution to this issue and found:
https://code.djangoproject.com/ticket/13217
"Enabling django.middleware.locale.LocaleMiddleware causes that django adds a 'Vary: Cookie' header to every reponse."
So localMiddleware adds header Vary: Cookie even in pre-flight OPTIONS response
There are lots of reccomendations to use djang-cors-header to fix some of this problems. But using this package function are equal to my settings on server-side.
I have also found pretty package: django-dont-vary-on which if installed can set decorators to turn off Vary:cookie, but in my case i need to turn off Vary:cookie only in OPTIONS response.
Im bit new to django and actually cannot even imagine what to do in this situation. Every my step is just like walking on a mine field.
Is there any solution or some alternatives?
You have to CORS whitelist your client to access the server.
In case their is a Cross-domain request, the request becomes preflighted if you use methods other than GET, HEAD or POST.
Also, if POST is used to send request data with a Content-Type other
than application/x-www-form-urlencoded, multipart/form-data, or
text/plain, it becomes preflighted.
Its the server that allows the cross-domain client request to be processed or deny it (default).
So if you have access to the server-side application, you could do the following to get the response.
On server-side
Install django-cors-headers on your server side and white list your client domain or IP (it is also port specific)
pip install django-cors-headers
In settings.py, add it in your INSTALLED_APPS
INSTALLED_APPS = (
...
'corsheaders',
...
)
Add the corsheaders.middleware.CorsMiddleware in MIDDLEWARE_CLASSES
MIDDLEWARE_CLASSES = (
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'**corsheaders.middleware.CorsMiddleware**',
'django.middleware.common.CommonMiddleware',
....
)
and define a CORS whitelist
CORS_ORIGIN_WHITELIST = (
'aaa.com',
)
Now as you have added your client in the CORS whitelist, you will now be able to make a successful ajax request.
While trying to redirect user to a URL, it works with GET requests but not with postback requests.
Through firebug's Network window, I can see the redirect response received by browser after the postback request (that should cause redirect) completes. The browser seemingly initiates a GET request for the redirect URL but doesn't actually successfully redirect. It remains there on the same page.
I use JSF server side. The initiated GET request is not received at all by the server. However initiated by the browser on server's demand. I guess problem is somewhere client side only
Can anyone please explain how to make redirect work successfully ? Let me know incase I should provide any more information.
Edit:
Request header for redirect:
GET /Px10Application/welcome.xhtml HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: application/xml, text/xml, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://localhost:8080/Px10Application/channelPages.xhtml?channelId=-3412&type=Group
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: hb8=wq::db6a8873-f1dc-4dcc-a784-4514ee9ef83b; JSESSIONID=d40337b14ad665f4ec02f102bb41; oam.Flash.RENDERMAP.TOKEN=-1258fu7hp9
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Response header for redirect:
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1 Java/Sun Microsystems Inc./1.6)
Server: GlassFish Server Open Source Edition 3.1
Set-Cookie: oam.Flash.RENDERMAP.TOKEN=-1258fu7hp8; Path=/Px10Application
Pragma: no-cache
Cache-Control: no-cache
Expires: -1
Content-Type: text/xml;charset=UTF-8
Content-Length: 262
Date: Wed, 22 May 2013 17:18:56 GMT
X-Requested-With: XMLHttpRequest
Faces-Request: partial/ajax
You're thus attempting to send a redirect on a JSF ajax request using "plain vanilla" Servlet API's HttpServletResponse#sendRedirect(). This is not right. The XMLHttpRequest does not treat a 302 response as a new window.location, but just as a new ajax request. However as you're returning a complete plain vanilla HTML page as ajax response instead of a predefined XML document with instructions which HTML parts to update, the JSF ajax engine has no clues what to do with the response of the redirected ajax request. You end up with a JS error (didn't you see it in the JS console?) and no form of visual feedback if you don't have the jsf.ajax.onError() handler configured.
In order to instruct the JSF ajax engine to change the window.location, you need to return a special XML response. If you have used ExternalContext#redirect() instead, then it would have taken place fully transparently.
externalContext.redirect(redirectURL);
However, if you're not inside JSF context, e.g. in a servlet filter or so, and thus don't have the FacesContext at hands, then you should be manually creating and returning the special XML response.
if ("partial/ajax".equals(request.getHeader("Faces-Request"))) {
response.setContentType("text/xml");
response.getWriter()
.append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>")
.printf("<partial-response><redirect url=\"%s\"></redirect></partial-response>", redirectURL);
} else {
response.sendRedirect(redirectURL);
}
If you happen to use JSF utility library OmniFaces, then you can also use Servlets#facesRedirect() for the job:
Servlets.facesRedirect(request, response, redirectURL);
See also:
Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same
JSF Filter not redirecting After Initial Redirect
I'm calling a server site on our internal server. This domain looks like this:
http://server.domain:12345/x.html
Now, with IE this works just fine, I'm getting the data. (My problem there is that IE caches the website after the first call forever, but never mind).
Now, if I'm trying to do exactly the same in Firefox, it won't work, the same in Google Chrome.
Firebug says this:
Answer-Header
Connection Keep-Alive
Content-Length 109
Content-Type text/html; charset=UTF-8
Keep-Alive timeout=5000
Server AbWeb Version SRSG 1.34
Set-Cookie sessionkey=80da7dfe-1c9c-4460-9592-3ce55cecb379
Request-Header
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Host server.domain:12345
Origin http://otherserver.domain
Referer http://otherserver.domain/test/
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Chrome says this:
X XMLHttpRequest cannot load http://server.domain:12345/x.html. Origin http://otherservere.domain is not allowed by Access-Control-Allow-Origin.
server.domain:12345/x.html
X Failed to load resource
It seems you perform cross-domain JavaScript calls. The target server must set the Access-Control-Allow-Origin HTTP header. In your case the server http://server.domain must set a header like:
Access-Control-Allow-Origin: http://otherserver.domain
I do not know why it works for IE, it may have to do with your security domains as your just working in the intranet.
See another example:
Jquery form doesn't show submission message on web server but it shows submission message on local host