My app shows a page with an image. If there is no logged-in user, it is possible to see the image although the following permissions have been set for the image file:
Does this work as expected? I have to enable RestUser to access the file from the web client. That’s fine. Then I thought, the roles “Authenticated User” and “NotAthenticatedUser” come on top. So my expectation was that a NonAuthenticatedUser (nobody is logged-in) cannot read this file via REST.
Am I wrong? I’m not using cookie-based authentication …
Opened the Page Preview without any authorization. As a result image is not showing in component (However will be shown if the NotAuthenticatedUser has the READ permission):
It would be better to describe details here so everyone from our team could see the step by step issue description.
However if those steps contain some sensitive information you can send an email to support@backendless.com.
We received your email, thank you for your patience.
We will now try again to reproduce the issue based on the data in the letter and let you know the results.
In the example from the email, you access the file because you use the CloudCode API key (you can find it in the link to the file). I want to warn you that using the CloudCode API key on the client is not secure. May I know the reason why you are using it?
Hi @Alexander_Pavelko ,
It comes as a surprise that, that the cloud key is part of the url. I did some research and found the root cause.
I’ve entered the URL of the image manually into a table using Console Data Browser (field image in table Collections). Whenever selecting the image file reference with following dialog
the system is automatically using the Cloud Key as part of the URL. Which is not good due to security reasons. In the section “Enter file URL”, I can even use the REST key when typing the URL manually, but this will be ignored and replace by the Cloud Key.
Hi @Alexander_Pavelko ,
I think I found the reason why the cloud key comes into play. I’m reading from a table using my own API service. The API service is accessing the table is fetching a dataset containing the image url. Then, on the UI client, I’m using this url to display the image via data binding.
Because the image url is fetched from the table via an API service, the cloud key becomes part of the image url. Could this be the reason?
I don’t know whether this behavior is good or bad, a bug or a feature. At least I must get rid of the cloud key. Maybe by replacing it in my API service by the REST key.
The cloud key becomes part of the image URL when your API service puts it there.
This is not a bug, but using the cloud key in this way is undesirable from a security point of view.
Please check your API service logic and try to use a different key when you save the image and make a record in the table.
Hi Viktor,
I’m not writing the image with the API service, I’m just reading it with the API service
The image has been uploaded via Console and the image field in the table has been set via Table Data maintenance in Console.
I tried to reproduce your situation. Like you, I uploaded images and added them to the table, but as a result, my link was formed with REST API key. Even if I inserted a link with CloudeCode API key in the “Enter file URL” field, the link was still automatically changed to a link with REST API key. And this is expected behavior.
So far I can’t figure out why you have a link with a CloudeCode API key generated when adding a file to the table.
Hi @Viktor_Mudrevsky ,
I’ve created a small example for you which reproduces the behavior:
Check my table Test and my API Service Test with method read. This method is returning a data record from table Test with a given objectId. As you see, there is only one record in this table. This record contains a field image which is a reference to one of my images on the server.
If you use the API Services test environment to call the method read, it doesn’t matter whether you invoke the service with REST API key or Cloud Code API key, the image URL always contains the Cloud key. Just try yourself …
when you call any backendless service like data or files from cloud code, by default Cloud Code Api key will be used. That is why you receive such values
I have created new model bl_support in your app to deploy my example and do not break something in your logic.
My example is very similar to your example Backendless. But as you can see I have hardcode object id and changed parameter to apiKey by default it use Rest API key. So if you provide JS API key your response will contain JS API key and so on. It works because I am reinitialized Backendless SDK in cloud code:
Backendless.initApp('your-app-id', apiKey);
Also, I have changed permissions for your Test table to allow retrieving data for the not NotAuthenticatedUser role.
And last note, if you use a custom domain you’ll always receive a response with a custom domain, no matter what API key was used, in our opinion, it is the best approach
Hi @sergey.kuk ,
Thanks for looking into this. Yes, I will go for the custom domain approach.
But it’s very valuable to understand how things are working in case I have to debug a problem.
