I am trying to understand how InertiaJS handles Laravel Redirects using back().
In the InertiaJS docs, this section:
Redirects
When making a non-GET Inertia request, via or manually, be sure to always respond with a proper Inertia response.
For example, if you're creating a new user, have your "store" endpoint return a redirect back to a standard GET endpoint, such as your user index page.
Inertia will automatically follow this redirect and update the page accordingly. Here's a simplified example.
For instance, in Laravel, when trying to reset the user password, the user clicks on the "Email Reset Link". This action on the server ends with a back()->with(). I've studied this request inside DevTools, and I can see a 302 Response with a Location response header.
It seems Inertia is intercepting this 302 response & requesting the Location specified.
In general, as far as I know, 302 are handled by the Brower, however, in this case, after the 302 requests, I see a GET request sent to the server for the Location with a request header of 'x-inertia': true.
Is it really InertiaJS handling this or does the browser send a GET request to the URK specified in the Location header and appends all headers from the previous request that caused the 302?
Appreciate your help,
Bill
Related
I'm using AJAX. I call the server which calls an API and gets its response. I try to return the response in JSON to the client. But my Laravel has Middleware that checks token is valid. And when it's invalid, it'll redirect to login page. So the response I return is not JSON from API call but is the HTML of the redirected login page. I don't know what to do about this. One, the response is not the expected JSON and two, how do I keep the mechanism of redirecting to login page when the situation is an AJAX call and not the usual going from one page to the next.
I'm trying to call(spring ) rest API which is protected using digest authentication using spring security and trying to access it from the redux front end. I'm getting a 401 response back to the front end, which has the response header WWW-Authenticate: also .. but unfortunately I am not getting the http basic authentication pop in my front end to enter the username and password.
Can someone help me in identifying the possible reasons for this? I'm able to get the http authentication pop up when I hit my rest API directly through the chrome.
Unfortunately, XHR requests do not trigger the auth pop-up. This will only happen if the main request (the html page you are loading or a redirect you make from that page) throws a 401.
The auth screen is also triggered if you load the request in an iframe. However, the credentials provided using the basic auth screen will not be passed on to other XHR requests. If you do use an iframe, you should respond with some sort of cookie and the subsequent XHR request should not need the basic auth screen again
Your options are:
Catch this error in your javascript and ask for the password using some interface you create yourself.
Make the same request in an iframe (or another request that will trigger the same security restriction) and respond with a session cookie upon success, then trigger the XHR.
Make an Login UI and ask for the credentials upfront, as you will need them for the XHR request.
From the client side, I am making an Ajax request of type "delete" using jquery.On the server side, I am doing res.redirect(URL).But instead of redirecting, browser is again making a delete request with URL returned from server side for redirecting.
However, it is not happening for a post request.Everything is OK with post request.
Short version
Ajax is trying to follow the request to it's bitter end to get a successful response (2xx). If you want to delete a resource and send the user to a new web page, you will need to handle that after receiving a success response from your Ajax call.
Full explanation
While redirects are sometimes used after processing a request (such as a successful / failed login) it's not really what they're intended for. Generally you would only redirect the user to get them to the resource their looking for. For example, you might move an endpoint such as POST /blog-post to the new location of POST /blog-article. What you're saying to the requester here is that something used to be where it is, but now they need to make a request elsewhere to find what they're after. This is incredibly important when trying to prevent link rot.
The idea of accepting and processing a request, and then moving the user off to another page is more of a coincidence really. It just happens to work due to how a browser handles URL requests.
I expect your POST request is actually using a form, in this case the browser is following the redirect because it received something like a 301 and is attempting to see a request chain through. However when using Ajax a redirect is being handled by the Ajax call itself, not the entire browser. Ajax in this case is acting as if you'd expect if the endpoint had been moved. So for example, if you moved the endpoint on the server side, your application would still function as it would follow the redirect instruction.
What you really need to do is return a successful response to your Ajax call such as a 204 (No content) and then in your frontend move the user on to a new page.
This isn't as convenient I'll admit, but when you understand why the redirects actually exist it makes more sense. They're not a way of telling a user to move onto something else, they're a way of trying to prevent link rot and enable applications to continue working against an API which may have changed slightly.
I am using polymer to send ajax requests to my Drupal services api.
I send a POST to login and then a POST to create a node. When I login I am given a token which I store and pass to the next request.
I am monitoring the the requests and responses with Charles, the token is being sent, the cookie is being set and passed on the 2nd POST but I get an "Unauthorized : CSRF validation failed" response.
When I send the request with Postman It works like a dream but for some reason it doesn't validate when sent with my app.
I have checked the token being set matches the one being sent and the only difference I've noticed is that when it's being sent again there is a prefix of ga_; something to do with google analytics?
The expiry of the token is a month away the token matches what is returned at login and is being sent correctly. The header accepts X-CSRF-Token in the Access-Control-Allow-Headers.
My CORS module code is:
api/*|<mirror>|GET, POST, PUT, OPTIONS|Authorization, Origin, Content-Type, X-CSRF-Token|true
If any body has a similar issue, mine was caused by a couple of things, running Drupal and my app in the same browser causing all kinds or cookie conflicts and when passing parameters to my function that computes my request, if there were any parameters that were not used it breaks.
Hope this helps someone.
Sometimes, a user session expires, no matter the reason. The user is redirected to the login page, as my routes sends the user there in case of Auth::guest().
Then it sends them back after successful login to an ajax/json page (like a list of images in json) - this happens because I'm using the Redirect::intended() call. This is completely unusable then - how do people work around this?
Using Redirect::guest() saves the requested URL to the session key url.intended. If you use Redirect::guest() in a filter on an AJAX route, this will still be the case and the URL of that AJAX call will be where the user is sent.
You can use if(Request::ajax()) {} to do something different for AJAX responses, like returning an error JSON instead of a redirect.