You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I add a custom error interceptor to the global Axios instance in my project that changes the shape of the error it will break Inertia's error handling (handling of 409 Conflict etc...).
I've opened an issue (https://gitlab.com/notabene/open-source/pii-sdk/-/issues/2) on their repo to ask them if they can create their own instance and not add interceptor to the global one.
But I believe this could also be done in Inertia as it also represent a security risk:
if a package is compromised and adds custom interceptor to perform malicious actions (e.g. steal credentials, etc...) inertia won't be protected and will send all of its request through it.
go back to the tab with the website without reloading it and click on any inertia link
normally you should see the request error with a 409 Conflict status code, which will not be handled by inertia to trigger the full page reload as the added interceptor changes the shape of the error which causes this part of the code
Versions:
@inertiajs/core
version: 1.2.0@inertiajs/react
version: 1.2.0Describe the problem:
If I add a custom error interceptor to the global Axios instance in my project that changes the shape of the error it will break Inertia's error handling (handling of
409 Conflict
etc...).for example, the following code from
@notabene/pii-sdk
adds an error interceptor to the global axios instance:https://gitlab.com/notabene/open-source/pii-sdk/-/blob/master/src/utils/create-client.ts?ref_type=heads#L42-63
I've opened an issue (https://gitlab.com/notabene/open-source/pii-sdk/-/issues/2) on their repo to ask them if they can create their own instance and not add interceptor to the global one.
But I believe this could also be done in Inertia as it also represent a security risk:
if a package is compromised and adds custom interceptor to perform malicious actions (e.g. steal credentials, etc...) inertia won't be protected and will send all of its request through it.
Steps to reproduce:
I created an example repo: https://github.com/LeTamanoir/inertia-axios-bug
I added interceptors to the global axios instance here: https://github.com/LeTamanoir/inertia-axios-bug/blob/main/resources/js/app.tsx
then you can do the following to reproduce:
run
npm run build
open the website in your browser and open the console and network tab
add a div in https://github.com/LeTamanoir/inertia-axios-bug/blob/5f3d9542fa521007920e4d9695666fa23718f83a/resources/js/Pages/Dashboard.tsx#L13-L14 (the file is not important, we just want to trigger a new build with new file names)
run
npm run build
go back to the tab with the website without reloading it and click on any inertia link
normally you should see the request error with a
409 Conflict
status code, which will not be handled by inertia to trigger the full page reload as the added interceptor changes the shape of the error which causes this part of the codeinertia/packages/core/src/router.ts
Lines 418 to 425 in efc3cc8
response
key is not present on the error rejected in the custom interceptor.To fix this I think creating a local axios instance in inertia's core package should be enough, happy to submit a fix PR if you want 🙏
The text was updated successfully, but these errors were encountered: