I still struggle with the problem of not being able to display images on the page using the access rights set in the security provider.
@Teodor has already answered that at the moment the Wappler is not able to give access to files in a non-public folder based on access rights, to display these files on the user’s page:
I wanted to ask, can this solution help to get around the problem?
Create a server action that has the download file step and the needed security in front of it. On your page you can have an image tag with the src pointing to the server action.
This method works perfectly and I successfully use it wherever you need a secure display of images, taking into account the security rules.
To show dynamic images, I have created a special route for this server action, with a parameter in which I pass the ID of the required image. All images are displayed correctly. But in a situation where I apply the route not on the content page, but on the layout, the browser console gives an error (the error does not affect the operation of the application, the route works correctly and returns the correct image):
I have some ideas about the cause of this error in the console. I think that the route starts loading faster than the client side server connect, which returns the image ID, loads. After the server connect on the client side is loaded, the route returns the correct image.
Although this does not affect the operation of the application, I wanted to know if there is anything I can do to prevent this error from appearing in the console?
The image loads as soon there is an url, you probably have an expression like {{ '/img_avatar/' + id }}, that returns /img_avatar/ when the id is not yet available. A workaround could be {{ id ? '/img_avatar/' + id : null }}, that will only return an url when there is an id and null when not.
The workaround works well. The error is no longer in the console. Thanks.
However, in the process of optimizing pages, I came across a much more serious problem related to this method. The problem is that using this method, the image will be loaded on the page as many times as the route will be repeated. Even if the route points to the same file. So if there is a table with 500 records on the page. And each entry is associated with the same image located in a non-public folder. Then when using this method, this image (the same) will be loaded on the page 500 times. This greatly affects performance. And with a large number of repetitions and a large weight of images, it can just fatally worsen the page loading speed.
What can be done to solve this problem in order to improve page optimization?
If the image has the same url, the browser normally will get it from cache when it is accessed multiple times. If you inspect the headers of the image url, does it contain some headers that would prevent the caching. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
I misinterpreted the cause of the duplicates. They do not occur because of this method, but because of the presence of the Preloader component on the page:
As far as I understand, this is the standard operation of this component. Below is a screen of the same page, but without the preloader:
As you can see from the traffic, the page with the preloader loads 4 times more traffic. For this reason, I have a question: how real is this load on the performance of the application with a large number of repeat?
The update fixes the issue of duplicate file uploads, however, a new issue occurs. The updated preloader never finishes loading (animation). It works endlessly, even when all the components and files are loaded on the page.
Seems that it doesn’t detect correctly if all the images are loaded. Here a new update for you to test, will also do some testing and post any new update I have here as a reply.
dmxPreloader.zip (1.3 KB)
In the last update, the preloader started loading correctly. The situation with duplicate files has been partially corrected (there are not as many of them as there were originally), but duplicates are still created:
Can you test if the loading screens goes away after typing dmx.requestUpdate() in the console.
Seems that browsers do not always trigger a load event on an image tag, so it will be difficult to track if an image is loaded. So the previous update is probably the best we can do for now, it only duplicates the images once and not more then that. Here the previous version again, hope I reverted the changes correctly.
dmxPreloader.zip (1.3 KB)
