homeplannz
Chevereto Member
Hi all,
We would like to request a change to Chevereto that we don't believe should impact other users, but resolves a long-standing issue we've been experiencing.
We store images in Chevereto then refer to the created URL links to Embed.ly - software that allows images to be embedded in other platforms, for example the Matterport 3D platform. We store the images under multiple user accounts, one per client, so they can access all their images. We have "Website privacy mode" set to "Private", and "Content privacy mode" set to "Force private (anyone with link can view)". This means the general public can't access the images, clients can log on to see their albums and images, plus we or they can share individual albums and images to their clients who don't need to log on.
While this setup works perfectly for user access via the web browser GIU, it causes an issue (intermittent 403 Forbidden errors) for Embed.ly. This is because the /embed endpoint within Chevereto requires that "Website privacy mode" to be set to "Public" to work correctly.
The change we are requesting is that, if "Website privacy mode" is set to "Private", and "Content privacy mode" is set to "Force private (anyone with link can view)", the /embed endpoint should not require any login credentials and work the same way as if the website was set to "public".
The rationale for this is, when you choose 'anyone with link can view', you are allowing anyone who knows the URL of the album or image to have access without a login. The fact that the URL is being accessed via the /embed endpoint should be no different. The rule should be if you are required to login to see something via the web browser GIU, then the /embed should require a login. If you are not required to login to access something in the GIU, the /embed should not require a login.
This is a critical request for us as we've been using Chevereto for a number of years with around 20,000 images stored. We've been chasing this intermittent 403 error for some time trying to find the cause. Resolving it means any Chevereto user who is using the /embed endpoint (and you probably are if you are referring to the URL from other platforms) will not have the same 403 issues.
We are not aware of a downside of this change. The 403 error is intermittent, meaning it is not enforcing the login every time an image is embedded, so this is not a security feature others can/should be relying on. I have been asked to put it in as a RFC given it is a change to the current functionality.
As an extension of this request, Embed.ly have invited Chevereto to submit their details and become a supported platform they work with - not doing this has slowed us down in sorting this issue. There are no costs involved, just a form to fill out and then they will check to ensure the platforms are compatible. If so, win win, Chevereto gets listed as a supported platform and others can use it like we do.
Comments/questions welcome.
We would like to request a change to Chevereto that we don't believe should impact other users, but resolves a long-standing issue we've been experiencing.
We store images in Chevereto then refer to the created URL links to Embed.ly - software that allows images to be embedded in other platforms, for example the Matterport 3D platform. We store the images under multiple user accounts, one per client, so they can access all their images. We have "Website privacy mode" set to "Private", and "Content privacy mode" set to "Force private (anyone with link can view)". This means the general public can't access the images, clients can log on to see their albums and images, plus we or they can share individual albums and images to their clients who don't need to log on.
While this setup works perfectly for user access via the web browser GIU, it causes an issue (intermittent 403 Forbidden errors) for Embed.ly. This is because the /embed endpoint within Chevereto requires that "Website privacy mode" to be set to "Public" to work correctly.
The change we are requesting is that, if "Website privacy mode" is set to "Private", and "Content privacy mode" is set to "Force private (anyone with link can view)", the /embed endpoint should not require any login credentials and work the same way as if the website was set to "public".
The rationale for this is, when you choose 'anyone with link can view', you are allowing anyone who knows the URL of the album or image to have access without a login. The fact that the URL is being accessed via the /embed endpoint should be no different. The rule should be if you are required to login to see something via the web browser GIU, then the /embed should require a login. If you are not required to login to access something in the GIU, the /embed should not require a login.
This is a critical request for us as we've been using Chevereto for a number of years with around 20,000 images stored. We've been chasing this intermittent 403 error for some time trying to find the cause. Resolving it means any Chevereto user who is using the /embed endpoint (and you probably are if you are referring to the URL from other platforms) will not have the same 403 issues.
We are not aware of a downside of this change. The 403 error is intermittent, meaning it is not enforcing the login every time an image is embedded, so this is not a security feature others can/should be relying on. I have been asked to put it in as a RFC given it is a change to the current functionality.
As an extension of this request, Embed.ly have invited Chevereto to submit their details and become a supported platform they work with - not doing this has slowed us down in sorting this issue. There are no costs involved, just a form to fill out and then they will check to ensure the platforms are compatible. If so, win win, Chevereto gets listed as a supported platform and others can use it like we do.
Comments/questions welcome.
