Sandcastle (the new Sandbox)

CesiumJS
1

Hi guys,

The first draft of Sandcastle is now ready for testing. Check it out from the branch of the same name. It is linked from the “index.html” in the main directory.

Note that the demo collection is NOT there yet, there are just some placeholder stubs for demos that test Sandcastle’s ability to bring up a Cesium window and debug it.

Save and load are mostly working, and the gallery needs more styling but it’s functional. Docs are hooked up, try double-clicking a class or a member function in the code editor.

JavaScript security doesn’t exist. You can’t host Sandcastle on any domain that offers user logins without causing a full security breach. There are conflicting goals in play: We want people to be able to host this locally from a development server, so I didn’t try to construct a dual-domain thing like jsFiddle uses for security. Suggestions welcome. We may have to host this thing from its own domain name with no logins (thus avoiding the whole problem). (Currently, cesium.agi.com has no user logins, so maybe this is a non-issue).

Note that Sandcastle is based off the “viewer” branch, not master, and will be merged there if viewer itself has not yet been merged to master when this thing is ready.

       --Ed.
2

Awesome. Is this is a state where I can start coarsely organizing and porting examples from the Sandbox? Or should we just play with it?

Patrick

3

Yes, it is ready to start getting updated examples from Sandbox. The HTML files in the gallery folder have a particular syntax about them, please don’t hand-edit those files for now. Instead, edit or paste new code into the Sandcastle live-editors, and use the “Save As” function there to create HTML files for the gallery.

    --Ed.
4

Cool. I’ll try to do some examples this week. Maybe Friday.

Patrick

5

Very cool! Can you elaborate on the security situation a bit? I didn’t quite follow you.

6

Hi Kevin,

Well I’m no XSS expert, but generally Sandcastle in its current form carries all the risk of the JavaScript eval() command, as it allows the user to eval arbitrary code (and Sandbox did this as well). The simplified version (which is all I understand) is that it allows potentially malicious users to execute their own JS as if it came from whatever domain is hosting Sandcastle (such as cesium.agi.com).

JS executes in a sandbox of the browser’s making of course, so barring any holes in the browser itself, the only risk is to the hosting domain’s users. For example, if cesium.agi.com had user logins with sessions and cookies, some eval()ed code from another domain could pretend to be on the cesium.agi.com domain, and gain access to those sessions or cookies, possibly gaining access to data intended to be private to a particular user, such as email or phone number. Other domains (including www.agi.com) are not at risk from this because the browser doesn’t consider them part of the “same origin” for actions that require a same-origin policy.

Since we don’t have any user accounts on cesium.agi.com, I don’t think there’s any security risk, but if other people are going to host copies of this on other domains, they should be aware of the risk. (See Wikipedia’s entries for XSS and Eval for more reading…)

  --Ed.
7

Hey guys,

One of the tricks I use is to declare eval as an empty object (window.eval = {}:wink: so that the function still exists, but it no longer executes the input, or declare it to be something that will log use of the function (window.eval = function(e){ report(e)});). Gotta love mutability.

Having said that, dynamically writing a tag () to the DOM will do the same thing as ‘eval’, and that’s a bit harder to protect against (and also the enabling principle of JSONP). In the end as Ed pointed out, “javascript security doesn’t exist”; however, there are things you can do to make your application much harder to hijack.

-TJ

8

Aah, I understand now. Thanks, Ed.

9

Ed

Sandcastle is awesome so far.

I attached a picture of our original design - not because we have to stick to it - but just so we have something beyond the hard copies floating around.

I committed an example for circles and ellipses ported from the Sandbox. I’ll be happy to aggregate and port the rest of the Sandbox examples, but first we need to make the starter code a bit more concise to lower the barrier to entry even more. More on that with all my comments below. You don’t, of course, have to respond to each of these individually.

  • At 162 lines with comments, the simplest example is way too much code. Let’s figure out how to make it as approachable as possible, e.g.,

  • Can we hide some of it in utility functions in the HTML/CSS tab - perhaps canvas.oncontextmenu, window.onresize, and “canvas.className = …” and the following line?

  • Can we just always use the 2048 textures? Absolutely.

  • A really bare bones example doesn’t even need the demo buttons or mouse handling skeleton; perhaps we need two skeletons: one that is really a skeleton and one that has other useful stuff.

  • The examples don’t need to include any calls to console.log, right? Those were just for testing?

  • Does Safari still need the proxy? If so, how long need we need to keep it for?

  • Adding demos to the gallery

  • Do we call them demos or examples? Either is OK as long as we are consistent (not that we are not already).

  • What will the workflow be for external users that want to submit to our gallery? To a public gallery?

  • View as Thumbnail is cool. What is the easiest way to save it? I took a screen shot and cropped it. Why can’t I right click and ‘Save As’ or something similar?

  • The Sandcastle subdirectories, gallery and templates, should probably start with uppercase like all the other Cesium directories (wheter all directories should start with lowercase is perhaps another question. I don’t care as long as things are consistent).

  • Do we only support .jpg? Why not .png too? It is pretty common, and actually what I tried to do first.

  • When I don’t show the demo buttons, “Loading, please wait…” never goes away unless I explicitly modify the div tag. Can we have default behavior for this?

  • There are some hardcoded references to dojo in the generated html file. Are they always required? We don’t want to tightly couple the examples with dojo.

  • What does a user do once they download the html file? They need to know to put it in the gallery folder for it to run, right? Should we have an option to package up Cesium and their example, so there is no barrier to entry for them to switch from Sandcastle hacking to local hacking?

  • Code editing

  • How feasible is JSLint or JSHint?

  • Syntax highlighting is nice, but has some flaws. For example, “polyline” is highlighted blue in “var polyline = new Cesium.Polyline();”

  • Tab inserts a tab. Can it insert spaces?

  • Is it possible to get line numbers for the reported errors? Better yet, can we highlight the line like you do in the GLSL Sandbox?

  • Ctrl-Space

  • When I bring up Sandcastle, I get “GET http://localhost:8080/Build/Documentation/types.txt 404 (Not Found)” unless I build release for the documentation, which is too slow to require people to do (2 minutes 38 seconds on my machine). How can we handle this? Make it optional? Submit a prebuilt one?

  • If I type "var v = new " then Ctrl-Space, I get intellisense, but it doesn’t include Cesium types.

  • General

  • I see the Bing logo, but where is the Cesium logo? Perhaps, we should make it part of Scene so it is on by default.

  • When I run with break on all exceptions, it breaks in contextRequire in dojo.js on load.

  • The examples shouldn’t include “scene.getCamera().frustum.near = 1.0;” Once the multi-frustum is in, we will have infinite near and far planes (well that’s not true, but you get it). Currently, setting the near plane to one causes the vector data to z-fight with the depth plane.

  • Moving forward

  • 2D and Columbus view are awesome Cesium features, but we haven’t fully put them at the forefront. How can we make it easy to switch to them in Sandcastle?

  • Gallery

  • The gallery page with mouse over widgets looks slick so far. How will we quickly browse and show several examples when demoing (like clicking on different items in the Sandbox tree)?

  • Can clicking on the screen shot default to something? Run or Edit, I’m not sure which.

  • Will examples have metadata extracted from JavaScript comments so, for example, mouse over on the gallery will show a description.

  • We need the ability to put spaces in the name, e.g., “Polygons and circles”, not “polygonsAndCircles.” How bad is it to just put spaces in the filename? Or include a display name in the metadata?

  • The gallery is sorted alphabetically, right? We probably want to sort it by date so returning users see what’s new. We might even want the option to sort it other ways, but let’s not get ahead of ourselves.

  • We’ll also want to be able to live search the gallery, including the code, e.g., show me all the examples that use Polyline.

  • Should the editor ask to save work when I leave the page like gmail? Should it automatically save? Can we do that client-side?

  • How important is are fork/parent buttons like the GLSL Sandbox?

  • How hard is it to support CZML down the road? GLSL?

Again, I think Sandcastle is fantastic. It is a major improvement to the Sandbox, which was already pretty impressive.

Patrick

IMAG0188.jpg
IMAG0188.jpg1024×612 40.6 KB