Hi Mark In case it wasn't clear, I was talking about reading local text files. I > wouldn't think there would have to be any security restrictions against > reading local files -- I can use the browser to browse to and read local > text files. >
You'd be surprised. As I said in my message above, Chrome doesn't allow code running from a file:// URI to perform local file access. Also, accessing file:// URIs is off limits in all browsers from http:// URIs. So, what browser(s) and operating system are you using? Can you share the paths you're using too? Best wishes Jeremy. > > Firefox 33, TW 5.1.8, Win 7 > > Thanks! > Mark > > On Friday, September 11, 2015 at 2:30:24 AM UTC-7, Jeremy Ruston wrote: >> >> Hi Mark >> >> On Thu, Sep 10, 2015 at 5:04 PM, 'Mark S.' via TiddlyWiki < >> [email protected]> wrote: >> >>> Is _canonical_uri supposed to work with text files? I can't get it to >>> show a simple text file with either an absolute address (provided by >>> tiddlysnip) nor a relative address. But it does work with absolute and >>> relative addresses of image files. >>> >>> What I mean is that the text of the text file does not show up in the >>> _canonical_uri tiddler. I tried saving the text file in the 4 different >>> file encodings offered by Notepad. >>> >>> It wouldn't even show me a text file in the same directory as the TW >>> file. >>> >>> I could get it to work with an absolute, but not relative path to a PDF >>> (with application/tiddler). >>> >>> It's odd that advanced file formats work but not a simple text file. >>> >> >> What browser and operating system are you using? >> >> The _canonical_uri field is handled very differently for images vs. text. >> For images, we just assign the URL to an <img> element, and there are no >> cross-domain issues. For text tiddlers, the equivalent approach would be to >> use an iframe. However, if we did that we wouldn't be able to access the >> actual text of the tiddler. So, instead we use xmlhttprequest, a JavaScript >> API provided by browsers since the dawn of time. The trouble with it is >> that browsers have implemented a number of restrictions on its use in the >> interests of security. Worse, those restrictions differ between browsers. >> >> One situation where external text tiddlers work consistently across >> browsers is when the TiddlyWiki HTML file is accessed over HTTP (or HTTPS) >> and the tiddler is on the same server (technically, on the same domain). >> Everybody should be able to see the full text of Alice in Wonderland here, >> even though it is a lazily loaded external tiddler: >> >> http://tiddlywiki.com/prerelease/index.html#Alice%20in%20Wonderland >> >> However, setting the _canonical_uri to a different server will only work >> if that server is "CORS enabled". >> >> The situation is not so good if the HTML file is being accessed on a >> file:// URI. In my tests, Chrome refuses to load the external tiddler, >> while Firefox is quite happy. >> >> The complexity of the implementation landscape is why I initially >> resisted adding this feature. As I feared, it's proving hard for many users >> to get it working because of the requirement to understand the browser >> limitations. >> >> Best wishes >> >> Jeremy. >> >> >> >> >> >> >> >>> >>> Mark >>> >>> TW 5.1.8, FF 33.0, Win 7 >>> >>> >>> On Wednesday, September 9, 2015 at 8:17:47 AM UTC-7, Danielo Rodríguez >>> wrote: >>>> >>>> Hello, >>>> >>>> Now I see that the canonical uri field can be used to point to external >>>> files that got rendered into the TW tiddler body, I want to point to some >>>> source code files. >>>> >>>> But, I am not getting any success. The way I'm doing it is using >>>> relative paths >>>> >>>> _canonical_uri: ../../Dropbox/somewhere/file.js >>>> >>>> I am using node.js version, maybe that is the problem? Should I use the >>>> standalone edition instead? >>>> >>>> I have to say that I find the name of the field hard to type. I >>>> remember a pull request to add a drop-down with common fields, was it >>>> merged? >>>> >>>> Regards. >>>> >>> -- >>> 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 post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/tiddlywiki. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/tiddlywiki/6db8a709-91e1-4ca8-90ec-8c170d78a15f%40googlegroups.com >>> <https://groups.google.com/d/msgid/tiddlywiki/6db8a709-91e1-4ca8-90ec-8c170d78a15f%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Jeremy Ruston >> mailto:[email protected] >> > -- > 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 post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/tiddlywiki. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywiki/e0e4755c-3199-4800-b2c1-f0743006fc88%40googlegroups.com > <https://groups.google.com/d/msgid/tiddlywiki/e0e4755c-3199-4800-b2c1-f0743006fc88%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Jeremy Ruston mailto:[email protected] -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAPKKYJZmRdPv%2BRv1T3C-%2BfsvpTDf879ANbFJHrfNVtwbFaG%3DHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
