Is there a way to edit my TW files from an iframe in another of my tw files?

#1

The title says it all. I am using Firefox. All the files are local standalones. I thought this used to be possible, but when I click the save button on the inner TW, it asks me if I want to download. So I cancel, and my changes are not saved.

#2

Dave, I will look into this a little later, what I do know is if you wish to save changes in the iframe it needs access to its saving mechaisium. I have found success with Bob sites in iframes as they save per tiddler anyway and are tolerant to multiple sessions being open.

Of course if your access is read only it is simplified.

What saver are you normally relying on for your problem iframed wiki?

Tones

#3

It does. Answer: yes.

I have a “host” TiddlyWiki that hosts (a this moment) 8 TWs, 3 are “open” for editing. The host and all hosted wikis are served up by TiddlyServer. Saving works fine.

#4

In case anyone’s finding this old thread:

For TiddlyHost files, you’ll need to modify the settings at the “Your sites” panel so that the target wiki (the one you’d like to glimpse through the iframe) is set to “Allow inside an iframe” (scroll to the bottom of the settings pane). By default this setting is not checked.

The settings panel warns: “It’s safer to leave this unchecked unless you particularly need it.”

Should we be worried about enabling this?

-Springer

#5

The risk is probably minimal for a TiddlyWiki on Tiddlyhost, but there’s a type of attack called “Clickjacking” which is only possible when iframe access is permitted.

What is Clickjacking? - YouTube includes a demo showing how it can work.

1 Like
#6

Thanks! I watched the video. So in theory, if I was already logged in at tiddlyhost (so that changes could be saved), AND a hacker could lure me to their custom-malicious site, I could be decieved into interacting with that page without realizing that I’m actually clicking through to make undesired changes on my own site.

I agree: with the vast majority of tiddlyhost sites, it’s hard to imagine the combination of hacker motives, GUI rigging, and phishing bait tactics that would all have to be in play to make this a real concern.

If anything, the relevant risk would come from letting tiddlyhost’s dashboard url (Tiddlyhost) appear in an iframe (which could in theory allow for clickjacking to change a site from private to public, or to delete it, etc.). But that possibility seems to be locked out entirely, even if I enable iframes for particular hosted pages.

I appreciate the TiddlyHost default protection, and your explanation, @simon!

1 Like