Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetchUtils.fetchJson behaves differently after authentication provider rejects promise #3088

Closed
mrwatts opened this issue Apr 3, 2019 · 2 comments

Comments

@mrwatts
Copy link

mrwatts commented Apr 3, 2019

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.

@fzaninotto
Copy link
Member

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.

@mrwatts
Copy link
Author

mrwatts commented Apr 3, 2019

Ok, thank you. I think I found the mistake. Can't believe I missed it all this time. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants