then host the iframe on some static site. however you can still trace these requests through the network requests so depending on how far your willing to go this may be your best option https://studio.code.org/projects/applab/5DNO3wlQtxLKDg4UTDPhtKRShW-a9g1NpmQlNbY4C1O/embed?nosource you can also run the link without the iframe if you do not wish to host it on a site yourself if you’d like
Another idea…I have also made a screen recording of the game or app being played. I use Screencastify (a Chrome extension) OR windows screenshot now has a built in screen recorder as well. Screencastify allows me to share a link to the video.
~Michelle
I see, this makes sense as this is how normal webquery requests work
My point being that people can still view your project even if noSource option flag is enabled either way by monitoring the console network tab that loads the code json from the actual project id
Which then from there all you have to do is put the correct parameters with the project id and then add /view to be granted access to the source code
It is something neat but will not deter those who are much more comfortable with code especially back end code queries
Also @Solis you have somehow managed to surface some bug with the noSource attribute, a very oddly specific one i might add
so by using hideSource or clicking the box generates a new id (as it is somewhat hiding the project id)but what happens if we use the obfuscated id like you did and remove the embed argument but keep the noSource attribute flag behind it? the result being that the getAttribute function returns faulty data without an embed and the noSource embed making it undefined behavior that was likely never supposed to happen
What happens in my Project?
I use a dynamic way to check an id for a project, that way when a project is remix the checkRecords call can get correct data from the project, which getAttribute couldn’t be spoofed or rather tricked by server end when the wrong id was supplied to the argument the response was a 404 because the project id is wrong while addUser relies on another function that can still accurately call the db and update it, but not to worry this has now been patched