HTML5 path traversal expansion?
Monkey Forums/Monkey Programming/HTML5 path traversal expansion?
| ||
| Hello, The way I've set up my folders in my current project, it makes loading paths with relative locations difficult, but specifically only on html5 because the metadata for some files rely on relative paths containing directory traversal shorthand. This shorthand is generated by the host application, and seems like really the only "sane" way to handle resources being loaded in a different folder from the file being generated that isn't a subfolder relative to the metadata file. The problem manifests when trying to load a resource using one of mojo's built-in functions, like LoadImage(). While relative paths are automatically expanded to their appropriate "monkey://" protocol prefix, path traversal shortcuts are not. What's the best practice for handling this? brl.FileSystem is not implemented for html5, so I can't get information about the underlying folder structure. I'm wondering if there's a good "catch all" way for mojo to handle this automatically (can all files within the data folder be made aware of each other somehow? Maybe coming up with an internal map during the build process? Is that a security risk?), or at least to have a pure Monkey solution, if that's even possible. But right now, all I can think of are workarounds instead of actual solutions. |
| ||
| I have to say that 5 months without even a response is killing any enthusiasm I had for Monkey.. I won't likely be purchasing. |
| ||
| This sounds incoherent. The state of the file you currently have open (Or last opened) should have nothing to do with the "file-system". To begin with, Monkey supports path resolution using its target system, and related code. So, something like Mojo would simply resolve the path and move on. Mojo uses HTML5's DOM types (And similar behavior) for most resources, meaning the protocols and paths supported are equivalent here. The unfortunate thing about Mojo's resource loading is that it depends on the build tool(s) to perform ahead-of-time meta-data collection. So, you can't really load images outside of your data folder, without going native. This is a weird optimization, and it's honestly not too difficult to patch out. On the bright side, normal Monkey games that don't try to load foreign resources are more secure, and quicker at detecting errors, which is nice. In addition, Mojo has 'FixDataPath' (From 'mojo.data'), which resolves paths to the proper prefix/parent directory. It essentially adds "monkey://data/" in front of the path if it's local. If you want to use a global path, you'll need to have "/", "monkey://", or "./" at the beginning. Otherwise, you're dealing with a local path, which will get resolved for most things. In particular, Mojo uses this natively for resources. This means you're implicitly using the "data" folder for images and sound files when it gets to the final build. Since we can't use anything else (By default) for resources, anyway, this makes sense. For those curious, here's the current usage in JavaScript. The 'FileStream' class is not supported on default HTML5, as it requires a real file-system, something that's not very easy. With that said, however, I have created a fully working file-system for WebCC ('FileStream' is on the TODO-list), but it's not really meant for this kind of usage. It also requires a number of modifications, so you'd need to use the WebCC (Requires work) or modified HTML5 targets. Those targets would also require the modified modules found here. Needless to say, you're not getting anywhere without some effort. That ecosystem was designed for out-of-project requests and the like, but it's not a cohesive product. Where does this leave custom formats? Well, not too far off. It's pretty common to see local paths in file formats, and normally, you'd have enough of a file-system to allow "cd-like" traversal. Monkey doesn't have that by default. That's the unfortunate thing about Mojo's HTML5 backend, and admittedly, it's one of Monkey's worst aspects. There's no official solution at the moment, so you'd basically need to keep track of file paths yourself. However, my module does handle path semantics on JS targets. Although it's tied to the rest of the code, I could break it up more. This is something I've wanted to do for a while, and I'm not entirely sure how to go about it yet. That's the gist of it, though. What's really annoying is the lack of out-of-project image loading in Mojo 1. More secure? Yes, but more effective? Not so much. Other than that, it has the same shortfalls as HTML5 with regular JavaScript. |
   |