White list domain for embedding a public model?

Hi guys,
Do domains now also have to be white-listed for public models? If so, when did you change that? Until a few days ago, this was only true for private models, see:

Full disclosure, embedding public models without white-listing domains should never have worked :wink:
We actually discovered this bug as we rolled out the new update. Indeed, it will now be required to white-list domains even for public models. You can consider this an upgrade, since it provides more security for your models, as before it would have been possible to embed them anywhere without restrictions…

Hi @mathieu1,

Thanks for the reply. We manage www.planenplanen.de for our client and as a result of this update, the configurator is now inaccessible for his clients. Actually, it still is as I can’t figure out what exact URL’s we need to white-list.
I understand the reasoning for the change. However, it would be very nice to get some kind of notification in the future. Or did I miss it? Besides, the documentation still speaks of private models, that need to get white-listed.

Besides, is it possible, that the direct embed code itself has changed, too?

Unfortunately, we were not aware of the previous bug and assumed that embedding without specifying domains was never possible. Our apologies for the inconvenience. The documentation has been fixed too.

Can you point me to the model you are trying to embed? If I have the link and can access the configurator, I should be able to figure out the domain you need to whitelist.

Yes, this is the model:

Thank you

Sorry for the delay, it turns out the embedded model was a different one: https://app.shapediver.com/edit/stgm-zsk-v0-6-aug-23-20-1326

We added the domain to it and it works again now. Sorry again for the inconvenience.

Ok, thanks. I was confused about the models because apparently the tickets for direct embedding are regenerated every time the model is opened. That’s why I couldn’t find the correct model by looking at the ticket we used for embedding. As it still working on that (old) ticket, the conclusion must be that there is a whole list of tickets that work for embedding. Is that assumption correct and why did you change it? In my opinion it is quite confusing.

I noticed the same problem with tickets for direct embeding. If you want to change embeding list model, or just change light parameters, you have to go to edit mode. After that ( work in edit mode), ticket will be changed. It is quite confusing and also can make a problem if you already set up UI based on previous ticket.

1 Like

The tickets are regenerated every time since the last update, and it is also a matter of improving security.

Please note that any generated ticket will work for embedding, you do not have to change the ticket every time you make changes in the model.

We agree that it makes it more difficult to find a ShapeDiver model using a ticket. We are thinking of a better way to give users the possibility to identify a model from a given ticket.

1 Like

Is there a place where we can see what was included in this update? It is quite a big change and something that you should tell your users about a bit in advance before doing it, but at least do it when you have done the update and don’t let users find this out by themselves. We have businesses that rely on Shapediver, you can’t just do these major changes silently!

Can you tell us what else you changed, because our process that uses the backend API is no longer working.

1 Like

We apologize for the way this update was handled. It was mostly a backend update but some design decisions there ended up having a direct impact on our users. We are working on being more transparent both in terms of scheduling updates but also on the contents of each upcoming one.

Regarding this update, it would be very technical to list everything that changed in the backend. It’s a lot! And essentially preparations for the much more visible updates to the frontend and plugin parts of ShapeDiver. The goal of the update was to do those preparations while preserving the legacy experience on the platform. So far, we have noted two breaking changes which have been reported on the forum:

  • It was previously possible to embed public models on any domain. This is now not possible anymore, embedding domains need to be specified for any model. The previous behaviour was actually a bug and therefore we did not take into account that commercially embedded models were not using any domains. As mentioned elsewhere, this new behaviour is much more secure.
  • The embedding tickets for models are randomly generated every time a request to view a model is placed. All generated tickets are valid for embedding so this change should not have broken any existing embedding.

Therefore it is not clear why the backend API is no longer working for you. Please send me a link to a model as well as the backend ticket you are trying to use and that is currently failing.

1 Like

Thank you for the thorough explanation of the changes.

I think it was more of a confusion on our part because of the changing backend tickets, which are used several times in our scripts, but were basically using 2 different backend keys, since we always assumed they would be the same if you just go into shapediver and open the model, which is now no longer the case.

I can confirm it is working again, now that we save the backend key in a Google doc and then copy/paste from there into our code.

I am actually kind of sad it is going the way of API keys being different even more, while I was secretly hoping that one day it might be possible to “re-upload” or update a model without having to update API keys everywhere. We are now at like iteration 19 of one of our scripts and updating everything always takes a good 15 minutes (since also the export codes change) and always introduce room for error, while having a simple “update definition” functionality where API key and export codes stay the same, would negate both the time lost and risk of error.