Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out and document how to upload an existing TW file to a Tiddlyhost site #55

Closed
simonbaird opened this issue Feb 20, 2021 · 5 comments

Comments

@simonbaird
Copy link
Owner

No description provided.

@kookma
Copy link

kookma commented Feb 20, 2021

One simple solution is to drag and drop your existing single Tiddlywiki.html over the newly created site on Tiddlyhost.
Then save and reload.

As an example see https://kookma.tiddlyhost.com/ which is updated with http://tw-tables.tiddlyspot.com/
I had to download http://tw-tables.tiddlyspot.com/ to my disk and then drag and drop over my online site on Tiddlyhost: https://kookma.tiddlyhost.com/

@Jermolene
Copy link

It would be nice to be able to fill in some details in control panel and save any TiddlyWiki across to TiddlyHost, regardless of where it is stored, as we could with TiddlySpot.

It looks TiddlyHost uses a cookie called _session_id to handle authentication, rather than the old basic authentication of TiddlySpot. I think that means that we'd have to provide another means for users to obtain their session cookie from tiddlyhost.com and then copy it to the wiki being saved, and the PUT saver would have to know to find the session cookie elsewhere.

In the meantime, perhaps it's easier to provide an upload button in the TiddlyHost wiki listing? That would also make it possible to publish in read only form older versions of TW5 or TWC that lack the new PUT saver.

@simonbaird
Copy link
Owner Author

A few thoughts:

  • I'm not sure if copying around the session cookie is practical, but maybe there's some other way to provide credentials. I'm imagning a site-specific authentication token could be created to allow saving a site without having a current login session at tiddlyhost.com.
  • The upload button idea seems reasonable. It would be fairy easy to create, but I wondering if we'd need to worry about validating that the file uploaded resembles a Tiddlywiki file. (Perhaps we can do that kind of validation when serving the file and refuse to serve the file if it looks suspicious.)
  • Similar to an upload button there could be a "replace site with file fetched from url" button.
  • For local TW file I believe it's no longer possible to "post" to the internet from a file://, (which would be a convenient way to upload a site if it was possible). Is that correct? Is there some workaround to allow "save to web" from a file:// url?
  • For a TW file somewhere else on the internet, I expect that CORS restrictions will prevent "save to tiddlyhost" from working easily.

@Jermolene
Copy link

  • I'm not sure if copying around the session cookie is practical, but maybe there's some other way to provide credentials. I'm imagning a site-specific authentication token could be created to allow saving a site without having a current login session at tiddlyhost.com.

Yes, that seems more robust; it could work very similarly to GitHub's personal access tokens: one would click a button on the TH control panel to copy the token to the clipboard, and then paste it into the target TiddlyWiki.

  • The upload button idea seems reasonable. It would be fairy easy to create, but I wondering if we'd need to worry about validating that the file uploaded resembles a Tiddlywiki file. (Perhaps we can do that kind of validation when serving the file and refuse to serve the file if it looks suspicious.)

I can imagine that one wouldn't want to make it too easy to upload non-TW files. Is there anything to stop users grabbing the session cookie and using Curl to upload arbitrary files now? Come to think of it, one could adapt TW very easily to save arbitrary files back to TH.

One perhaps crazy approach would be to store tiddlers rather than TW files, and dynamically splice them into a template with the latest core (perhaps with a query parameter to allow overriding the core version used). I think that might be the only way you could guarantee that you're serving a bona fide TW.

  • Similar to an upload button there could be a "replace site with file fetched from url" button.

Could be handy, but wouldn't work for file:// URIs.

  • For local TW file I believe it's no longer possible to "post" to the internet from a file://, (which would be a convenient way to upload a site if it was possible). Is that correct? Is there some workaround to allow "save to web" from a file:// url?

As I recall, POSTs are blocked on one browser (maybe Chrome?) but not another (maybe Firefox).

  • For a TW file somewhere else on the internet, I expect that CORS restrictions will prevent "save to tiddlyhost" from working easily.

True.

On balance, the file upload option seems the best approach, if the security/DMCA concerns can be squared.

@simonbaird
Copy link
Owner Author

The upload button was added via 93a7367 , so I think that's enough to close this. See also this guide on uploading.

Notes:

  • Being able to save to Tiddlyhost from a TW hosted somewhere else is interesting, but we'll track it elsewhere maybe. I think it's likely to come up again under the topic of CORS.
  • The approach I've taken re uploading arbitrary content is to allow the upload, but then refuse to serve a site if it does't look like a TiddlyWiki. Fooling the "looks like" test would be possible, but perhaps it's enough to discourage casual misconduct.
  • Consider the idea of user/password or token key/secret based site saving #72 is open to consider the user/pass or token/secret uploads idea
  • I'm thinking about the possibilities of chopping and reassembling TW files from their tidder data, but I think this something for later. (Nokogiri makes it fairly insert and remove storeArea divs.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants