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
Related
I have created a multi auth system for Laravel and I can log in and protecting the routes (with web and admin) defined in web.php is working fine. Now I also want to do the same for the api calls in api.php. For this purpose, I have installed Passport, changed my auth.php file to passport for api, attached the token in Kernel.php and in my axios request I attach xsrf and XMLHttpRequest. But when I execute my api call I get all the time 401 Unauthorized. I have taken a look in my headers and see a laravel_token and X-XSRF-TOKEN, so I am puzzled why it is not working.. Does anybody have any idea? Thanks!
Header looks like:
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: undefined
Connection: keep-alive
Cookie: XSRF-TOKEN=eyJpdiI....
DNT: 1
Host: 127.0.0.1:8000
Referer: http://127.0.0.1:8000/availability/calendar
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Mobile Safari/537.36
X-CSRF-TOKEN: 4SUDy8IJigeEBftGjTVgat7cqPSGnncA0zuSiEeI
X-Requested-With: XMLHttpRequest
X-XSRF-TOKEN: dsfjkdsfsdj.....
In my api.php:
Route::post('/userStuff', 'MyController#userstuff')
->middleware('auth:api');
And my axios request:
axios.get("/api/userStuff").then(({data}) => {
console.log(data);
});
I have http get method called by client side to the server, but when ran it, the method is OPTIONS, here is the output i am seeing in Chrome Dev tools, for the GET Method,
Request URL: http://localhost:9090/area
Request Method: OPTIONS
Status Code: 500
Remote Address: [::1]:9090
Referrer Policy: no-referrer-when-downgrade
Response headers,
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: authorization, content-type
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: http://localhost:4201
Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Connection: close
Content-Length: 0
Date: Tue, 20 Mar 2018 18:49:59 GMT
Expires: 0
Pragma: no-cache
Vary: Origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
and Request headers are,
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Access-Control-Request-Headers: authorization,content-type
Access-Control-Request-Method: GET
Connection: keep-alive
Host: localhost:9090
Origin: http://localhost:4201
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Why the GET method is not getting called, i know there are already some answers here, but i did not understand well, can some one please help me for clear understandig? Thank You in advance.
The OPTIONS request is what is called a preflight request from the browser. In a simple way is basically the browser sending an initial request to the server asking for permission to then do a GET or POST or any other verb. This happens whenever a request needs permissions to be executed. If the server replies saying you have permissions to run the request you intend to, it will then perform the initial request (GET in this case). If the OPTIONS request is denied, it will not execute any subsequent request. You can see it as a way of testing the waters for requests :)
The reasons to be denied may be several. You might not have the correct headers, you might be missing authentication or authentication token, and so on.
From what I can see on your requests you are doing the requests from localhost to localhost. That will cause you problems with CORS.
Here’s a link on how to configure CORS for spring ( the server you said you are using in the comments below )
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.
There are a lot of questions on this subject, but I still can't seem to resolve my issue.
I have a game that I'm trying to get working with HTML 5 in Chrome. Link here.
The game is written using libgdx and I'm posting json data from my app engine hosted back end. I've done quite a bit of reading and I think I understand the issue with cross domain access, I also think I understand how to resolve it but can't.
The full error is
XMLHttpRequest cannot load http://1-1-51.wordbuzzweb.appspot.com/Login. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://wordbuzzhtml5.appspot.com' is therefore not allowed access.
As you can see, this says No 'Access-Control-Allow-Origin' header is present on the requested resource.. But if I look at the headers for the requested resource, they are as follows.
Date: Thu, 18 Jun 2015 21:59:34 GMT
Content-Encoding: gzip
Server: Google Frontend
Vary: Accept-Encoding
Access-Control-Allow-Methods: GET, POST
Content-Type: application/json
Access-Control-Allow-Origin: *
Alternate-Protocol: 80:quic,p=0
Cache-Control: private
Access-Control-Allow-Headers: Content-Type
Content-Length: 127
As you can see, there is an Access-Control-Allow-Origin header included.
If someone could please tell me what I'm doing wrong, that'd be appreciated.
The request header is as follows using the POST method.
Host: 192.168.254.1:8081
Pragma: no-cache
Cache-Control: no-cache
Origin: http://localhost:8080/
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.52 Safari/537.36
Accept: */*
Referer: http://localhost:8080/html/
Accept-Language: en-GB,en;q=0.8
Content-Length: 25
Content-Type: application/json
Since you are getting some headers back in the response, that's a good indication that the request IS reaching the server, however, the fact that it isn't hitting your server route points to the problem being the request being made doesn't match any of your routes. The request is likely an OPTIONS request rather than a POST request, which commonly happens when you make a CORS request from the browser that isn't a "simple request".
The solution would be to either make it a "simple request", or to have your server respond to OPTIONS requests. It's far easier to just make your server respond to OPTIONS requests, because sometimes even "simple requests" still send OPTIONS requests.
I'm trying to get Firefox to allow me to make an XmlHttpRequest for data from an application port.
I can see that the initial send triggers an OPTIONS message, and I have trapped this using NetMon, and I can see the HTTP fields...
OPTIONS /any.htm HTTP/1.1
Host: www.mysite.co.uk:10090
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Origin: http://www.mysite.co.uk
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
I respond to this with an OK to tell FireFox to get a move on and send me the data in the XHR request...
HTTP/1.1 200 OK
Access-Control-Allow-Methods: POST,-GET,-OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Max-Age: 172800000
Server: Kawasu-OrderSub
Date: Wed, 23 Jan 2013 15:00:50 GMT
But the POST is never sent, which I assume means that FireFox is not happy with the 200 OK response. The POST sends data with a Content-Type of "application/json"
I've got FireBug and the Net tab has the XHR button, but this will only show the XHR after the pre-flight check has been passed.
Main Question: How can I see (and debug) what FireFox does not like about the server response?
Much obliged for any help in advance.
You need to include the Access-Control-Allow-Headers: content-type response header. This is because the request has the Access-Control-Request-Headers: content-type header, and this value needs to be included in the response.