• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.

Privacy Controls & Direct Access

LEckley

💖 Chevereto Fan
Hi Everyone,

I have been kicking around the idea of launching an new image hosting site, however I am uncertain if Chevereto would be the ideal solution due to how privacy is controlled/handled.

Unless I am missing something, when a user uploads an image to a private album the image is still accessible via its direct link allowing viewers/users to still view the image no matter how the privacy settings are set.

When uploading new images its not a huge issue as no one would really know the direct link, however if a user shares an image via a direct link and then decides to make it private the privacy change has no impact.

Is there a plan to increase privacy or change Chevereto to allow an image to be truly private?

I am guessing it would require a complete change to the Chevereto core?
 
Unless I am missing something, when a user uploads an image to a private album the image is still accessible via its direct link allowing viewers/users to still view the image no matter how the privacy settings are set.

The visibility will depend on the album privacy setting:
  • Private: Only the owner of that album will see the images that belongs to that album
  • Private with link: Anyone with the link will be able to see the content
  • Private with password: It will request the album password to see its contents
  • Public: Anyone with the link will be able to see the content and the album and its images will get listed / available for search
Is there a plan to increase privacy or change Chevereto to allow an image to be truly private?
Images are now truly private depending on how the user sets the album privacy.

Note: The system doesn't rely in the image direct URL for privacy or anything. The direct image URL will be always public. That won't change.
 
Note: The system doesn't rely in the image direct URL for privacy or anything. The direct image URL will be always public. That won't change.

I believe this answered my question and is my exact concern, even if a user changes the privacy settings the direct link to the image will always be visible/available.

My concern is when a user changes the privacy of an album I want it to effect changes on the direct link as well, similar to how your competitor Reservo is handling it.

I may have to look into using another script unfortunately :(
 
Dynamic media load is out of the question for Chevereto because for every image load (embed, direct open, anything) you will be triggering a new dynamic request in your server which is very expensive for the scope of Chevereto based websites. Server resources will get a heavy impact in any system using PHP to deliver media.

To put it simple, when you control the actual image request you will be calling not just the resource but you will hit MySQL and open a new server thread to serve that dynamic request. It will be extremely easy to get that server down with even the slightest usage of the system.

If the competitor does that (dynamic media load) I'm afraid that it is because this people don't know how bad dynamic media request can hit your server. I don't know if they do that or not, I'm not into sniffing their functionalities.

The only improvement left to be made here is to change the image filenames on privacy change, that's easy for local storage and a little bit harder for external storage. If you want such feature please open a new topic in Requests, Ideas and Suggestions section.
 
Last edited:
Dynamic media load is out of the question for Chevereto because for every image load (embed, direct open, anything) you will be triggering a new dynamic request in your server which is very expensive for the scope of Chevereto based websites. Server resources will get a heavy impact in any system using PHP to deliver media.

To put it simple, when you control the actual image request you will be calling not just the resource but you will hit MySQL and open a new server thread to serve that dynamic request. It will be extremely easy to get that server down with even the slightest usage of the system.

If the competitor does that (dynamic media load) I'm afraid that it is because this people don't know how bad dynamic media request can hit your server. I don't know if they do that or not, I'm not into sniffing their functionalities.

The only improvement left to be made here is to change the image filenames on privacy change, that's easy for local storage and a little bit harder for external storage. If you want such feature please open a new topic in Requests, Ideas and Suggestions section.
They do have support for mod_xsendfile, which should alleviate the resource consumption from PHP.

Changing the image name would also change the Chevereto page link for the image as well, correct?
 
They do have support for mod_xsendfile, which should alleviate the resource consumption from PHP.

mod_xsendfile is intended to be used in systems where you don't stream content but just download it. Ideally you want a system that doesn't depends at all from PHP or MySQL and mod_xsendfile just process headers sent by your output handler. All permissions, access, whatever is still being handled by PHP so the problem remains, you are still hitting the backend and therefore you are still wasting too many resources to serve static files. Taking into account that the module will process the file, the impact is because of new MySQL connection and a new PHP thread.

No one will embed a zip file but an image is made to be embedded and what you will get is that every image load will be actually a load of the entire system vs load a static resource which is several times faster and cheaper.

I think that I can make a system that at least leave MySQL out of the equation and improves performance by using OPCache and local storage (javascript).

There should be workarounds to make it cheaper but at this time I'm not into it because the demand for this feature is too low. If mire people get interested I could take a look and eventually add it in an upcoming release.
 
Last edited:
Back
Top