Field 'path' in the payload request is being mistakenly updated when error

Hi support,


In FileManager, let's say I make a request to get files in folder /tmp. Then let's say I have folder 'root' that is only accessible by super user (which I am not). I (double) click into the folder and I get an error of permission denied. Behind the scenes, a request is made:

{"action": "read", "path": "/tmp/root/", ...}

It looks ok, the error message is legit because I have no permission on that location.

Then I repeat the same action and I look again at the payload of the request:

{"action": "read", "path": "/tmp/root/root/", ...}

The path is /tmp/root/root/ which is wrong, it should still be /tmp/root/ because the previous action was unsuccessful.


8 Replies

IL Indhumathy Loganathan Syncfusion Team June 20, 2022 02:54 PM UTC

Hi Renato,


Greetings from Syncfusion support.


We have prepared a React File Manager sample with access rules to deny read permission for the specific folder as per your explanation. But the read request doesn’t trigger for the access denied folder. We have used the below rule to deny read access to the “Documents” folder.


new AccessRule { Path = "/Documents/", Role = "Default User", Read = Permission.Deny, Write = Permission.Deny, Copy = Permission.Deny, WriteContents = Permission.Deny, Upload = Permission.Deny, Download = Permission.Deny, IsFile = false },


Sample: https://stackblitz.com/edit/react-rboqyy?file=index.js


Service provider: https://www.syncfusion.com/downloads/support/forum/175707/ze/Sample-Service-1565913320


Also, refer to the below documentation for reference.


https://ej2.syncfusion.com/react/documentation/file-manager/access-control/


Please check the sample and service provider to enable access rules at your end. If we misunderstood, reproduce the issue in the above shared sample and revert to us. If possible, share with us the video footage of the issue with the package version used in your sample. These details would help us assist you promptly.


Regards,

Indhumathy L



RE Renato June 21, 2022 11:13 AM UTC

Hi support, thanks for reaching out.

Ok I setup a a test server for this. In the accessRules files, I have this:

{
"role": "Administator",
"rules": [
{
"path": "/tmp/root/",
"isFile": false,
"role": "Administator",
"read": "deny"
}
}

My /tmp/root/ permission mode is 0700. Nothing happened, I was able to access the folder:



Now (step 2) from /tmp I want to go to /tmp/test/. But before doing that, I add a file to /tmp/test/root/ as root (/tmp/test/root/test.txt). The result is:


The server error is:


It seems like the server tries to perform list the content of each folders in /tmp/test, it finds a root folder and performs a stat on a file owned by root, and it throws an exception. And that's ok, that's an error more or less expected (one could always catch the exception).

Now (step 3) I start the server again without reloading the client (from the client perspective, it's like the server never crashed) and I try to repeat the same action: from /tmp to /tmp/test. The result is:


The server error:


My point is that the client is updating the state of the variable representing the destination path even though there was an error, as shown in step 2. In that example, the application still considered I was able to cd into /tmp/test, which is not true because it failed due to an error in the server (no permission to stat file). I close my error popup message, and try to repeat the same action: cd into /tmp/test. But because the value of path was wrongfully update to /tmp/test, now a "read" action is issued to /tmp/test/test, which is wrong because the path is incorrect.

My suggestion is that "path" must not be updated in case of an error, either by checking the http response error and check for anything != 2xx or reading the value of a response int the form of {"error": {"code": 4xx, ...}}

Sorry for the long post, but I wanted to illustrate the issue to make it easier to understand and I consider this issue has a major impact in what would otherwise be a really great component.



IL Indhumathy Loganathan Syncfusion Team June 27, 2022 10:59 AM UTC

Hi Renato,


We understand that you are facing some issues at your end. But in order to reproduce the exact issue at our end, we need some additional details. Please share us the below details.


  1. Have you written your own file service provider? Or do you use our service provider? Please confirm the provider used at your end using the link provided below.

              https://ej2.syncfusion.com/react/documentation/file-manager/file-system-provider/

  1. Your way of writing access rules is different from the mentioned way. So please share with us the complete code snippets.
  2. Have you made any custom changes to your back-end service provider?
  3. Have you set the path property to set the folder to be selected at initial rendering?
  4. Are you facing this issue on any specific device?


These details would help us assist you promptly.


Regards,

Indhumathy L



RE Renato June 30, 2022 11:49 AM UTC

Hey support, thanks a lot for taking a look. I am surprised you were not able to reproduce it. Let's start by answering the questions:

  1. I haven't, I am using the service provided by you, more specifically the NodeJS one. I follow the documentation, I start it with `node filesystem-server.js`
  2. I am running this on MacOS but any BSD or Linux based system should do it
  3. I did minor changes but nothing that changes the behavior of those components. For instance, I made the server answer to calls made to api/FileManager/FileOperations since the react app queries that url on the examples mentioned in the documentation. The base code is the github one.
  4. I didn't. My initialisation object is displayed below and I am not using the path property. I also don't think that property is relevant.
  5. const hostUrl = "http://localhost:5000/";
    <FileManagerComponent
    id="overview-file"
    allowDragAndDrop={true}
    ajaxSettings={{
    url: hostUrl + "api/FileManager/FileOperations",
    getImageUrl: hostUrl + "api/FileManager/GetImage",
    downloadUrl: hostUrl + "api/FileManager/Download",
    uploadUrl: hostUrl + "api/FileManager/Upload",
    }} view={"Details"}>
    <Inject services={[NavigationPane, DetailsView, Toolbar]}/>
  6. I am running this on my chrome browser on my MacOS but I also don't think it should make a difference.
  7. this wasn't asked but the version of my react components are these:
  8. "@syncfusion/ej2-base": "^20.1.50",
    "@syncfusion/ej2-buttons": "^20.1.50",
    "@syncfusion/ej2-file-utils": "^20.1.47",
    "@syncfusion/ej2-react-filemanager": "^20.1.47",

As additional information, let me give you the list of steps you could take to easily reproduce it:

  1. clone repo from github
  2. install node packages (npm i) and make those modifications specified on 3 (from list above)
  3. run the following sequence:
    mkdir /tmp/test
    sudo mdkir /tmp/test/root
    sudo chmod 0700 /tmp/test/root
  4. start server with node filesystem-server.js -d /tmp
  5. start the client with npm start
  6. Navigate to the browser on localhost to the FileManager component and go to /tmp/test (double click on test)
  7. Acknowledge that there was an error on the client. Close the error popup and do not refresh the browser
  8. Acknowledge the error on the server which should look like this:

      Error: EACCES: permission denied, scandir '/tmp/test/root'

      at Object.readdirSync (node:fs:1405:3)

      at /private/tmp/server/server.js:1051:28

      at FSReqCallback.oncomplete (node:fs:199:5) {

      errno: -13,

      syscall: 'scandir',

      code: 'EACCES',

      path: '/tmp/test/root'

      }

  9. Since the server crashed (like shown in step 8), simply start it again like step 4.
  10. Repeat step 6, which means retry navigating to /tmp/test/
  11. Acknowledge that there was an error on the client, we can ignore.
  12. Acknowledge a different error on the server which should look like this:
  13. [Error: ENOENT: no such file or directory, scandir '/tmp/test/test/'] {

    errno: -2,

    code: 'ENOENT',

    syscall: 'scandir',

    path: '/tmp/test/test/'

    }

  14. In browser developer mode, notice the request payload:
  15. action: "read"

    data: [,…]

    path: "/test/test/"

    showHiddenItems: false


In step 13 you see that the path value in the payload of the POST request is not correct: it's querying the filesystem on the path /tmp/test/test . That is not correct because that path doesn't exist and naturally throws a file not found error in step 12. The bug that leads to this is in step 6-7. The issue there is that the path state in the component is updated to /tmp/test/ even though there was an error communicated by the server. Therefore the state shouldn't have changed and the current path should still be /tmp and not /tmp/test/. And because the actual path is now updated to /tmp/test/, then navigating to 'test' folder will append '/test' to the actual path and try to go to /tmp/test/test/. If I repeat the same action it will go on and I end up querying paths like /tmp/test/test/test/test/...

It should be rather easy to solve. The path component state should not be updated if there is an error coming from the server.

I hope that this quick guide will help you reproduce the issue and my explanation helps you understand it, but let me know, I can always provide some more clarity where needed.

Thanks again




LD LeoLavanya Dhanaraj Syncfusion Team July 5, 2022 02:23 PM UTC

Hi Renato,


Currently, we are validating the reported issue in the React FileManager component on MacOS machine. We need some additional time to reproduce this issue, and we will update you with further details on July 8, 2022.


We appreciate your patience.


Regards,

Leo Lavanya Dhanaraj



RE Renato July 5, 2022 02:48 PM UTC

Hey guys ,


Thanks a lot , I am looking forward for your progress and let me know if I can be of help.

I do work in a MacOS, but I am sure it can be reproducible in other Unix based systems.


Renato



IL Indhumathy Loganathan Syncfusion Team July 6, 2022 05:57 AM UTC

Hi Renato,


We will validate the reported issue at our end and revert you the details as promised.


Regards,

Indhumathy L



PM Prasanth Madhaiyan Syncfusion Team July 14, 2022 11:00 AM UTC

Hi Renato,


We have created a separate ticket (391992) for the reported query. Please track the ticket for further technical assistance.


Regards,

Prasanth Madhaiyan.


Loader.
Up arrow icon