Question: using the browse widget to fill the _canonical_uri field and do other things

[Pit.W.]

Hello All,

probably this my question is real stupid and everybody knows this:


1. The Situation:

*all takes place on a local PC / USB stick, no online action involved

*I have a TW-file in a folder which is filled and filling up with .pdf files

*I want to read the files and comment them in my TW local file
(standalone, not on node)

2. Question:

can the <browse> widget be used to perform the following functions:

*select a .pdf file

*open a template tiddler

*transfer the relative address of the .pdf file into _canonical_uri
field of the opened template

**and the filename to other fields?

*while also dealing with special characters?

*set the type to application/pdf (could be done by the template)

*then. display the .pdf- file within a tiddler


3. Request: could the browse widget be adapted to perform (2.) above?


Probably this is either known to everybody except me. Or it is impossible.

Enlightnment would be highly appreciated.


Kind regards


Pit

[PMario]

Hi Pit,

This thread and linked example TWs may be interesting for you. https://groups.google.com/forum/#!topic/tiddlywiki/TL8N40F0DVQ

-m

[Mark S.]

I'm guessing that the answer is "no", since we've been told that drag and drop can't do what you want (what I want too, BTW), because the file folder structure is hidden from the browser for security reasons. How this helps security is pretty unclear.

You can use TiddlyClip in conjunction with local clips and a browser tab that browses the local file system to create tiddlers based on file paths like you (we) would like.

HTH
Mark

[Lost Admin]

On Wednesday, August 2, 2017 at 10:38:18 AM UTC-4, Mark S. wrote:

I'm guessing that the answer is "no", since we've been told that drag and drop can't do what you want (what I want too, BTW), because the file folder structure is hidden from the browser for security reasons. How this helps security is pretty unclear.

The very short "how this helps security" for a lot of the pain, including this particular pain point, is pretty simple. Javascript comes from servers that the end-user doesn't control and shouldn't trust. Malicious developers (including advertisers and people trying to make bot nets) have taken advantage of the loose controls that browsers implement to put files on your computer without you even needing to do anything other than go to a website that happens to have an ad on it. The ad loads some javascript, the javascript puts files on your computer and runs them. Bam, you have a virus or worm or trojan or ransomware or spyware etc. You didn't have to do anything. It's called a drive-by download.

The other way around also works in that the javascript can look at files on your computer and tell your computer to send them somewhere, thus stealing information from you without you even knowing.

If the browser lets the website (javascript) set the path and name of a file and allows overwrite of existing files, then the javascript can replace proper normal programs with their trojans etc.

This, and may other attack scenarios keep coming back, even after the developers think they've fixed the problem. It isn't that the developers don't know how to fix the problem, they do. But the fix is to fix the underlying design flaws in the browser and significantly restrict what all that code from websites can actually do on the end-user's computer.

[Mark S.]

But we're not talking about a web-based javascript (or at least I'm not). We're talking about a local javascript file. And we're also talking about a user who has just navigated to a file, voluntarily providing file and path information. Whether the script is malicious or not, it already has full access to the contents of the file, and could conceivably send it anywhere. So why not let it see the path?

Thanks,
Mark

[Lost Admin]

On Wednesday, August 2, 2017 at 12:11:20 PM UTC-4, Mark S. wrote:

But we're not talking about a web-based javascript (or at least I'm not). We're talking about a local javascript file. And we're also talking about a user who has just navigated to a file, voluntarily providing file and path information. Whether the script is malicious or not, it already has full access to the contents of the file, and could conceivably send it anywhere. So why not let it see the path?

Because people are idiots and would run the local javascript without first making sure it doesn't contain malicious code.

And, because browsers aren't meant to open local files except for the purpose of uploading them somewhere. The other uses, like ours, are a nice-to-have because it's easy to implement.

[@TiddlyTweeter]

JavaScript runs well in TW WHEN its matched to it.

BUT its necessarily fussy because TW IS JavaScript and you can't just launch any-old-thing on it. You have to follow the rules.

So the irony is: TW IS Javascipt+ but engaging with it is much harder than doing any old JavaScript. Grasp this: Any JavaScript you add needs to interface with the JavaScript its already running, in one way or another.

Josiah