• 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.
  • Chevereto Support CLST

    Support response

    Support checklist

    • Got a Something went wrong message? Read this guide and provide the actual error. Do not skip this.
    • Confirm that the server meets the System Requirements
    • Check for any available Hotfix - your issue could be already reported/fixed
    • Read documentation - It will be required to Debug and understand Errors for a faster support response

Images not working with Matterport/Embed.ly platform (intermittent)

H

homeplannz

Chevereto Member
Hi, recently I asked if you could apply to Embed.ly to be a supported platform. We use Matterport which references to stored JPGs via Embed.ly, have had an issue occur but they will not provide us with support if Chevereto is not on the supported list.

So with that in mind, here's the issue which is occurring more and more frequently. Images we upload and save in Chevereto are not able to be referenced from Matterport. Here is an example:


This URL works if pasted in a browser, but results in a 'can't find media. Please check URL' error when referenced from Matterport (via Embed.ly). If we use the medium ('.md.jpg') URL link that Chevereto provides that one works.

Yet this photo, uploaded in exactly the same way and at the same time, same resolution works just fine:

We've tried editing the photos, saving as PNGs, changing the resolution etc but cannot find a common thread.

Can you please have a look and provide some guidance?
 
Sort by date Sort by votes
Your website has a login gate, which overrides the access to /embed. If this bothers you open a RFC explaining why we should have public /embed for systems requiring login.
 
Upvote 0 Downvote
Thanks, but not sure I understand. In global settings we set privacy to private, which allows us to select that photos should be private/with link. I thought this meant that anyone with a URL link to an album or image could view it without login - same way an unlisted YouTube video works?

If it is set to private/with link, then the /embed access should not be requiring a login?
 
Upvote 0 Downvote
Yes that is the setting I am referring to. It you set this to public, then you loose the option to then select private/with link. Access to the web site is not public, but users are not required to log in - they receive the URL link to the albums or photos which gives them direct access with no requirement to register? We've been using it that way for years. The 'with link' setting should remove any requirement for login access?

And please note the 403 is an intermittent error - I've just done an image now and linked it as we normally do, no problems this time.
 
Upvote 0 Downvote
Private mode = login required for any application Endpoint.

Direct access to image resources is not an application Endpoint.
 
Upvote 0 Downvote
Great to understand this issue. To summarise what you're saying if I have it right - referencing images stored on Chevereto via the embed.ly interface utilises the /embed application endpoint. This endpoint requires album security to be set to 'Public' to function correctly. If set to Private (including with link), we may experience intermittent 403 errors.

If this is correct, then returning to your first comment: "open a RFC explaining why we should have public /embed for systems requiring login." I believe if the setting is set to private/anyone with the link, this should result in public /embed. As the link is not secured by the system login, there is no reason to restrict embedding the URL in any way. Users can access the album/image without requiring login - so why should the embed function require the login?
 
Upvote 0 Downvote
homeplannz said:
so why should the embed function require the login?
Click to expand...
I don't know, it was just designed like that? Like I said, open a RFC and explain others why you think that such thing is wrong and how it should be improved. I won't address concerns about design decisions outside the RFC section, you aren't the only user of this software.

Why I ask for RFC if I'm right here talking with you? Simple, that's how I allow collaboration and that's how I expect users to collaborate.
 
Upvote 0 Downvote
Cool stuff, that's what I'll do, sorry I didn't understand your processes. I still don't understand why it would return errors only sometimes - if it's a permissions thing would expect allow or deny on all.
 
Upvote 0 Downvote
Hey again - I've got to say, something must have changed in the most recent release. We've gone from this being an intermittent issue on very few images (and for some reason, floor plan images) - to now the embed not working on every image. This is a significant issue for us.
 
Upvote 0 Downvote
We've just run a series of tests. We have changed the web site privacy to public, then on an album tested it as either public or private with link. We are getting the 'can't find URL' error which we were told by Matterport/embed.ly is as a result of a 403 error. If the issue is the /embed endpoint requiring it to be public, why are we still getting the same error when we change the site settings?

This album is public: https://imagelibrary.homeplan.nz/album/30-nelson-street-petone.yvc2. Image URLs all fine when viewed in a browser, but 95% not working via /embed (I finally got 1x thumbnail URL to appear).

Can you please investigate further? Based on your notes above, setting it to public should have resolved. Major issue for us as it means all our customer systems that access our 20,000 images are down 🙁
 
Upvote 0 Downvote
homeplannz said:
Can you please investigate further?
Click to expand...
No, this is out of my scope. That's why I moved it to Community support.

I applied for a provider account at embedly, but I think that the issue is on your server provisioning. Website loads slow, the intermitence could be just timeout issues. That is something you need to investigate, perhaps invest in a better server setup.

20,000 images is a low count for a Chevereto installation, there must be something else in your setup. TTFB is really odd, takes forever to load a simple listing.
 
Upvote 0 Downvote
I will raise with TMD, end of last year we scaled up to their Business Cloud (https://www.tmdhosting.com/cloud-hosting.html) when we consolidated sites. That slow load has only just come in yesterday, I noticed it straight after changing the site from private to public.

Is there debug tool or log file you can provide from what you did look at to help us with the 403 errs? I'm raising this with embed.ly (please let me know if that accepted our application as being a supported platform helps immensely), TMD as our host, Matterport as the other end point.

I don't know where the problem is, but there is a problem that wasn't there on this scale a few days ago, and it's killing us.
 
Upvote 0 Downvote
You should consider to hire a server administrator. I can't help you with this in a professional manner, is out of my scope.

Status for access should be at the access log, the 403 could be issued by your webserver or the app.
 
Upvote 0 Downvote
Access log is reporting 200 - success when accessed from iframely debug, though iframely and embed.ly still returning 403 error. Access log says:

104.248.82.218 - - [17/Mar/2021:05:36:13 +0000] "GET /images/2021/03/16/0ee0cafe-5d66-4e97-8475-fba2d484c943.jpg HTTP/2.0" 200 1 "http://debug.iframely.com/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36"

Further testing with web site set to public, folder to public:
https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-7.jpg >> Generates 403 error
https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-8.jpg >> Works

The only difference between these two images is "7" has image compression turned up in Photoshop, and "8" has it set to max. We played with file site, compression, ICC but all come back with mixed results:

https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-6.jpg >> works
https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-5.jpg >> works
https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-4.jpg >> does not work
https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-3.jpg >> does not work
https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-2.jpg >> works
https://imagelibrary.homeplan.nz/images/2021/03/17/30-Nelson-Street-Petone-1.jpg >> does not work

These were all different iterations of resolution and file compression, we could not find a common thread to what worked and what did not.
All the above were using the iframely debug. Embed.ly testing produced different results, no pattern I can spot.

TMD advise no server side issue they can identify, it is an issue with either Chevereto or Iframely + Embed.ly.

I have raised the issue with both Iframely + Embed.ly but as both are having an issue, they will point to Chevereto.

Tested against a different Chevereto instance and no problems - just our site generated the errors.

We are so stuck and lost with this!
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top