I would caution on being too hasty with this. There are some serious security implications with opening wikis hosted on the file system (i.e. file://, not talking about local servers or TiddlyDesktop).
Apparently permissions are shared pretty broadly for anything open on file://. The code I shared is probably ok, but I have reported one issue to the Chromium team that I would like to hear their feedback on since it has some potential security implications for TiddlyWiki. I know there are people who store very valuable data on their wikis which is why I want to put a big caveat on all this. Even with my current concerns, I believe that the API is very safe so long as you serve the wiki from a local server (any local server, doesn't need to be TiddlyWiki specific). For example, launching a web server in a directory with the wiki via "python3 -m http.server". There is less of a benefit over the tiddlywiki node server, but I do think there is still a benefit. Since there is almost no coupling between the server and TiddlyWiki, you can debug things entirely in the browser and synchronization of state is easier to think about. There is only the state on disk and the state of the browser tab, no hidden state/watch issues with the web server. I think expanding the code to support wiki folders would be great and would help solve some of the issues around having images embedded in portable wikis. I am planning on releasing this as an actual plugin, but in addition to security and versioning, I want the plugin to: - Support versioning/backup like TiddlyDesktop. - Have settings for the plugin to control stuff like logging from the component itself without modifying code. Thanks, Dyllon On Sat, Apr 24, 2021 at 9:15 PM TW Tones <[email protected]> wrote: > Folks, > > This may be the opportunity to simplify saving and give the local storage > plugin or its equivalent safe access to the local system. Thus users can > access a read only online resource and use it as if it were a local app, > with their own data stored locally. > > Any way to reduce the complexity of using, especially saving tiddlywiki(s) > will increase adoption. If the logic and and setup can be included in the > original wiki then they become eminently deployable with self documented > setups. This could include backups, localisation or cloning, I can quickly > do this now with Timimi already in place, if such facilities can be > introduced without a two step, browser specific install, all the better. > Yes, all the appropriate authorisation is needed for security. > > Tones > > > > > On Saturday, 24 April 2021 at 17:42:18 UTC+10 Jeremy Ruston wrote: > >> Hi Dyllon, >> >> >> I wrote a small module for saving using the Chromium file system API >> (which is in the process of being standardized). >> >> Example TiddlyWiki 5 Saver Using HTML 5 File System Access API >> (github.com) >> <https://gist.github.com/slaymaker1907/7a04a6188179bfe113b122b1f51e22b5> >> >> >> Great stuff, I’ve been following the File System API with interest, and >> would be keen to get a saver in the core once the spec settles down. >> >> Here’s a link for those unfamiliar: >> >> https://web.dev/file-system-access/ >> >> I don’t know if any other browsers are planning to implement the API. It >> seems like an obvious requirement for ChromeOS, but perhaps other browsers >> will have less incentive to implement. >> >> The first time a save action is triggered, it prompts for a save location >> but future saves should go to the same location. >> >> It's a bit dangerous because if saving fails, there is no way AFAIK to >> disable the saver after it loads. I would be interested to know if anyone >> knows a way to disable a saver after it has already loaded. >> >> >> I think you’re already following the correct approach: for the save() >> method to synchronously return false if the save cannot proceed so that the >> next saver in the cascade gets a chance. >> >> Another thought with respect to the File System API is that it may be >> possible to write a syncadaptor module so that we can support TiddlyWiki >> folders containing individual .tid files in the browser. >> >> Best wishes >> >> Jeremy >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "TiddlyWiki" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/tiddlywiki/IczqdIdC3lE/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/6d3bc90f-54eb-4512-a56d-3a62931b75b4n%40googlegroups.com > <https://groups.google.com/d/msgid/tiddlywiki/6d3bc90f-54eb-4512-a56d-3a62931b75b4n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAJsXKEMU2-R3asA6jOZOB35NQca7mpaxnT%3D%3D6sZiev6XVvWG-g%40mail.gmail.com.
