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
Problem
I am encountering a difference in the behavior of fetchUtils.fetchJson after my authentication provider rejects a promise. The difference is that before the authentication rejection, fetchUtils appends a slash after the url, and after authentication is rejected, it no longer does.
Expected behavior
I expected fetchUtils to behave consistently, so either to always append the slash, or to always omit it.
Steps to reproduce:
Start development server
Do some work
Get api to return 403
React-Admin redirects to login page
Api calls no longer work.
Related code:
My data and authentication providers have been taken largely from the standard tutorials and examples.
I have my api connection string in a .env file as follows:
REACT_APP_SERVERURL=https://localhost:44363/api
My authentication provider handles unauthorized requests by rejecting the promise, as follows:
// called when the API returns an error
if (type === AUTH_ERROR) {
const { status } = params;
if (status === 401 || status === 403) {
localStorage.removeItem('token');
localStorage.removeItem('permissions');
return Promise.reject();
}
return Promise.resolve();
}
Other information:
If I add the slash to my api url in my .env file, I can workaround the issue. But then, the slash is always added, so my urls look like this:
https://localhost:44363/api//resourcename/etc/etc
This was my initial configuration. But I didn't like the double slash, so I removed it in my .env file, and that works. My url look like this:
https://localhost:44363/api/resourcename/etc/etc
However, after the server returns a 403, React Admin will redirect to the logon page, and after entering credentials, the urls will look like this:
https://localhost:44363/apiauthentication
which should be:
https://localhost:44363/api/authentication
The wierd part is, that if I stop and restart the development server, it doesn't help. The problem remains. That is, until I edit my .env file and append the slash, so it looks like:
REACT_APP_SERVERURL=https://localhost:44363/api/
Then, api calls will work again. However, the extra slash is appended again too! So my api urls look like this again:
https://localhost:44363/api//authentication
Then, if I stop the development server again, remove the trailing slash from the .env file, and restart the development server, everything is back to normal. That is, until my server returns a 403 Forbidden response of course. Then, the whole story starts again.
Environment
React-admin version: 4.8.4
Last version that did not exhibit the issue (if applicable): unknown.
React version: 16.8.6
Browser: Chrome
Notes
I experienced this behavior too after upgrading React-Admin from 2.6.2 to 2.8.4. At that time, I interpreted it as something that had changed between versions. I added the slash in my .env file because I thought React-Admin was no longer adding it. But that is apparently not the case. After upgrading, I also experienced the issue mentioned in #3007. At the end of that issue, I mention the steps I took to get translations working again. After doing that, the extra slash appeared again too. Don't know if it could be related.
The text was updated successfully, but these errors were encountered:
This is probably due to your authProvider or dataProvider, as react-admin doesn't handle URLs directly. There is nothing we can do in react-admin. I suggest you ask your question on stackOverflow.
Problem
I am encountering a difference in the behavior of fetchUtils.fetchJson after my authentication provider rejects a promise. The difference is that before the authentication rejection, fetchUtils appends a slash after the url, and after authentication is rejected, it no longer does.
Expected behavior
I expected fetchUtils to behave consistently, so either to always append the slash, or to always omit it.
Steps to reproduce:
Related code:
My data and authentication providers have been taken largely from the standard tutorials and examples.
I have my api connection string in a .env file as follows:
REACT_APP_SERVERURL=https://localhost:44363/api
My authentication provider handles unauthorized requests by rejecting the promise, as follows:
Other information:
If I add the slash to my api url in my .env file, I can workaround the issue. But then, the slash is always added, so my urls look like this:
https://localhost:44363/api//resourcename/etc/etc
This was my initial configuration. But I didn't like the double slash, so I removed it in my .env file, and that works. My url look like this:
https://localhost:44363/api/resourcename/etc/etc
However, after the server returns a 403, React Admin will redirect to the logon page, and after entering credentials, the urls will look like this:
https://localhost:44363/apiauthentication
which should be:
https://localhost:44363/api/authentication
The wierd part is, that if I stop and restart the development server, it doesn't help. The problem remains. That is, until I edit my .env file and append the slash, so it looks like:
REACT_APP_SERVERURL=https://localhost:44363/api/
Then, api calls will work again. However, the extra slash is appended again too! So my api urls look like this again:
https://localhost:44363/api//authentication
Then, if I stop the development server again, remove the trailing slash from the .env file, and restart the development server, everything is back to normal. That is, until my server returns a 403 Forbidden response of course. Then, the whole story starts again.
Environment
Notes
I experienced this behavior too after upgrading React-Admin from 2.6.2 to 2.8.4. At that time, I interpreted it as something that had changed between versions. I added the slash in my .env file because I thought React-Admin was no longer adding it. But that is apparently not the case. After upgrading, I also experienced the issue mentioned in #3007. At the end of that issue, I mention the steps I took to get translations working again. After doing that, the extra slash appeared again too. Don't know if it could be related.
The text was updated successfully, but these errors were encountered: