Backendless Support
 
In Progress

Viewing files through console/file reference is rejected

Hello

If you set the permission on a folder or file to be denied for nonauthenticated users, then I noticed that you can't view the file through the console - data-file reference

So let's say you have a table with a column referencing the file. Then you login to the console, click on the table, choose a record and click on the file reference to view the file then it treats you as an outsider and won't let you view the file.

Shouldnt the person logging to console have the highest permission and be able to view files through data table like when going to the files system. Not to. Mention that he would be already an authenticated admin user

Leave a Comment

Comments (10)

photo
1

Hello,

User logged in to console is not a user from your app. It is important to differentiate users from your app (the Users table) from the developer who logs in to the console.

You can view a file using the built-in viewer:

d4c4b6acd6524d1d4648e229a43725bc

Regards,

Mark

photo
1

Hello Mark

But a a developer who logs on to the console is an admin meaning they should have superior permission over any user. Developer can already change and remove permissions of any user and can view files using the files system built in viewer, why cant he view the files from the file reference in table?

The beauty of the dashboard is that the developer (or owner) can see all the users registered navigate through all the linkages by clicking on references. So in my structure, if the developer wants to see all the files a user uploaded, he just choose the user and they click on file reference to see all the files. How can I enable him to view the file being clicked on?

To go through the file system, one would have to rmember the full path and navigate to each file one by one

You see my point?

photo
1

A developer can view any file if you use the built-in view/editor.

If you want to view a file as a user, you can use our postman integration and execute any API (including file download) as a logged in user.

Regards,

Mark

photo
1

Perhaps I am not able to explain the issue well. Please note that all the viewing I am talking about now is through the console. I am adding screeshots to assist. So As a developer, I am supposed to have access to everything including viewing files (since I am able to log in to the console).

When I log in to the console and I check the user table, here is what it looks like

e1fbcdaf50cad31b6ba6e97ccdcc0208

Then if I click on 1:N Relation for the test2 user row, it will load the following screenshot

e1200414581c98a7497c2b74c009a605

As you can see, these are all the documents for that test2 user.. Now me as a developer logged in to the console, if I click on any of the files above, it tells me "permission" denied!. But if I go to the fileviewer screen and try to figure the path for a specific file then it lets me open the file. At the end of the day, I am the same person (developer) accessing it from 2 different screens. Why one would be different? More importantly, is there a way I can allow the developer(myself) to view the file by clicking on the file name in the 2nd screenshot above. I find it hard to compromise the security and give access to the files to non authenticated users just so as a developer I can open the file by clicking on it in screenshot2.

photo
1

As documentation explains it, every file has 2 urls in Backendless:

1. Public URL - the one which is used by end user apps

2. Private URL - available only to the developer

When you fetch a file via (1), all security permissions are enforced. For example, if the file is denied access to non-authenticated users, you will be able to fetch it without a valid user token. The URL for (1) can be copied to the computer's clipboard by clicking the "Get Public URL" icon.

When a fetch a file via (2), it is absolutely necessary to include the "auth-key" header into the request. That header is established when you login to console and is present for every single request made in console. The URL for (2) is available by copying file URL for the file's hyperlink shown in console:

82616bf329d7901e7932acd816883396

Hope this helps.

Regards,

Mark

photo
1

  1. That header is established when you login to console and is present for every single request made in console

Exactly!. So why is clicking on the file in screeshot2 in my previous post, giving me permission error and not allowing me to see it? The "clicking on it" should be a request made with the established header since I am logged in to the console, as per your explanation above.

Question makes sense?

In technical terms, when clicking on the file reference "in the console", the private url should be the one being used not public url

photo
1

We were talking about 2 different things all along. I kept describing the Files section while you're talking about navigating to a file from Data. I see what you are saying now. This is something we should be able to correct.

Regards,

Mark

photo
1

I had a feeling this was going on and this is why I said let me try to explain it better with screenshots :)

I am so glad we were able to convene and thank you for your time. Please let me know when you think this can be corrected

photo
photo
1

Hi Mark,

Can you please provide me an ETA when this will be corrected? Because that will impact when to go live. Thank you

PS: The status of the post should probably be changed from "not a problem"

photo
1

Hello,

I cannot provide an estimate yet. The way it will be handled once we make the changes will be identical to navigating to related geopoints (that is it will open the Files screen and show the file there).

However, this is not a trivial change for the following reasons:

  • Files referenced by data objects can be an outside URL. It can be even a URL to a file located in another Backendless app.
  • A file may not be located on the first page of the file listing, hence simply opening up the directory will not be sufficient.

We have entered this request in our tracking system, but it has not been prioritized yet as we do not have available resources to allocate at the moment to this issue.

Regards,

Mark