NoScript and Zotero NOT working together

I'm running NoScript and Zotero 2.0.9. And I get this message for records with notes:

"The NoScript extension is preventing Zotero from displaying notes. To use NoScript and Zotero together, whitelist the 'file://' scheme in the NoScript preferences."

Nothing I do with the whitelist in NoScript seems to work (except disabling it).
  • It works fine for me if I whitelist "file://". Did you actually try that?
  • (And restart Firefox?)
  • I figured out a fix that worked. A bit of a work around. I think the problem is on the NoScript end.

    1> go to the NoScript Preferences whitelist
    2> import the whitelist as a text file
    3> Manually open the text file and add "file://". (I actually took care to put it in it's alphabetical order {likely unnecessary})
    4> From the Preferences whitelist tab select all sites and "Remove Selected Sites".
    5> import the modified text file in the NoScript Preferences whitelist tab.
    6> A restart of Firefox didn't seem necessary for this fix. But if steps 1-5 don't work, then try a restart as well.

  • Glad you got it working, but others really shouldn't need to do all that. Just entering "file:" and restarting Firefox should work fine.
  • edited October 14, 2010
    I had the same problem as d0gg0nit. The problem was that I had file:// already on the noscript whitelist, and still got the error message with zotero notes. Here's how I got mine working:

    I first tried steps 1-5, and it didn't work. then restarted, but it still didn't work. After this, what I did was closed the zotero window, went to noscript preferences, removed only the file:// entry from the whitelist, pressed Ok, went back to the preferences and whitelist tab and put the file:// entry back there, pressed Ok and restarted firefox.

    Not sure whether it's a problem with noscript or with zotero, actually. I think I had the zotero window open, when I did d0gg0nit's steps 1-5. Might have affected the process?

    Edit: forgot to mention that I'm using the same versions of both add-ons as do0gg0nit (NS 2.3.3, Z 2.0.9).
  • I'm having the same problems as described above by ktkallio and d0gg0nit. I'm running Iceweasel version 3.0.6 (the version that is included in Debian lenny), Zotero 2.0.9 and NoScript

    What's different for me is that none of the workarounds seem to work for me. I've tried to add file:// as well as file: and even both at the same time to my NoScript whitelist. I did that via the NoScript preferences dialog as well as using d0gg0nit's trick and I've restarted Iceweasel over and over again, but it didn't work out. The procedure described by ktkallio didn't help either.

    What puzzles me, is that I can't see any errors or warnings in neither Zotero's debug output nor in the Firefox Error Console. Shouldn't there be any hint of what's going on behind the scenes?

    The only thing that has helped so far is disabling NoScript as long as I want to edit or read notes in Zotero. But obviously this is not very convenient...

    If you need any further details, I'd be glad to supply them...
  • You should be able to test the whitelist entry by browsing to any file:// URL in Firefox, e.g. 'file:///'. If I browse to that without the whitelist entry, I see a NoScript warning at the bottom that lets me whitelist 'file://'.

    Note that this is in 3.6.10. It's possible that NoScript has problems with earlier versions of Firefox.
  • MG6
    edited October 16, 2010
    I'm running Windows XP, Firefox 3.6.10, Zotero 2.0.9, and NoScript The suggested fix isn't working for me, either. It only just started happening; I believe I updated NoScript on this machine yesterday, and Zotero just now. I have restarted Firefox about 5 times. It does not come up on the block list by itself, and the NoScript whitelist greys out "allow" if I enter any // after "file:". I notice NoScript began blocking Zotero snapshots only a few weeks ago. Has anyone reported this bug there?
  • You don't need the "//". It's just "file:" (though file:// works for me, and if I navigate to file:/// and whitelist it through the menu, it shows up as file://). Make sure you've tried that method.
  • MG6
    edited October 16, 2010
    Thanks. I used "file:", and "file://" actually (pressing enter adds it to the list), but no dice. NoScript is not working as you describe for me.
  • PS: I am also having the same problem on my MacBook, with all the same version numbers.
  • I tried your suggestion and browsed to file:///. NoScript told me (via the "everything's fine"-Icon ;) ) that it allowed scripts for this site. I then revoked the permission and added it again by selecting the menu entry "Allow file://". Then I restarted Iceweasel and tried again, but it's still not working...
  • I emailed NoScript support. Please try this fix, which has worked for me. The additional step of a NoScript options reset did the trick.

    "OK, upgraded to 2.0.9 (2.0.8 was the latest version served by AMO, and it worked with no special permissions).
    I immediately found that I couldn't edit any note without allowing file://, as correctly stated by the message given in place of the note.
    Either adding "file:" or "file://" did work, but only ON NEW WINDOWS, i.e. I had either to spawn a new window from the File menu or restart the browser in order to have the notes editable in the Zotero panel after changing the permissions (probably because the file:// scripts are loaded at window startup time).
    If this doesn't work for you, please try NoScript Options|Reset, then adding back file:// to your whitelist (which got reset)."

    So, I had to perform the NoScript Options Reset, the button for which sits at the bottom of the window. I also had to restart my browser a couple of times. Be sure to export your NoScript whitelist first, because it will be deleted permanently. Everything seems to work fine now.
  • I tried this one too but it didn't help either. I also can't confirm the statement about new windows. In the meantime I also updated NoScript to, which didn't change anything either.

    Has anyone any ideas how to debug this or generate useful debug output to see what is going on?
  • edited October 21, 2010
    You could try to test it on an empty Firefox profile?
  • Thanks for the suggestion, but that didn't help either.

    I'll try to ask the guys over at NoScript whether they know how to enable debug output or something like that for NoScript, so I can see what exactly is being blocked. I'll report any interesting findings here.
  • I promised to report back on this, so here are my results:

    I asked in the NoScript Forums ( and there is indeed a very verbose debug mode implemented in NoScript:

    Quoting Giorgio Maone:
    about:config, set noscript.consoleDump to 1 and noscript.consoleLog to true.
    Warning: this can be very noisy and impact browsing performance.

    I tried that, but it didn't yield anything useful. I see that Zotero tries to load something from a JAR file and succeeds. With NoScript disabled there are tons of entries about Zotero loading various files. But when NoScript is enabled, there are only one or two messages, but no errors or reports about any file being blocked by NoScript.

    I have no idea what else to try, so I'm giving up.
  • I've developed another problem since this started, and I think it might be related to the whole noscript vs zotero conflict. Zotero will not longer allow me to edit links embedded in notes. <Insert/Edit link> no longer calls up a dialogue window. And this also happens with accessing the HTML code for a note. All the other options (bold face, italicize etc) work fine.

    Anybody have any ideas on what might be causing this?
  • d0gg0nit: There's no need for anyone to speculate. Test it yourself by disabling NoScript.
  • Thanks
    Did that. Ran it with noscript disabled and then enabled. Am wondering if extension is screwing things up. Am trying to remove now.
  • any hope for solution?
    I have the same problem, running zotero 2.09, noscript, firefox (iceweasel) 3.0.6 (linux debian lenny)
  • Allowing "file:" via the NoScript menu worked for me and that's why it didn't work before:
    The "file:" entry also was in the list of untrusted addresses.
    This list cannot be directly reached via the NoScript settings but only via "about:config".
    So either delete the entry manually via "about:config" (noscript.untrusted) or, what I did because it's easier, open a local file that Firefox can show via the Firefox menu: File>open.
    Now opening the NoScript menu, the "file:" entry was shown in the sub-menu for untrusted addresses. "Allow 'file:'" and restarting Firefox solved the problem.

    The entry was both added to the whitelist and removed from the untrusted list.

    I was confused because the problem now occurred a second time after I had set "file:" to the whitelist some time before. The first time the problem had been solved immediately with the entry in the whitelist.
    The entry to the list of untrusted addresses must have come after this first time. I don't know how, whether it was by a NoScript update or by my mistake. Anyway, now it works again and I found a solution. I hope this also works for others.
  • With firefox 3.5.16 it works for me now.
  • I was just coming to share my fix, but I see that Bege solved it a month ago! I also found that "file://" was blacklisted (adding "file:" to the whitelist alone didn't counteract it). I couldn't see my blacklist within noscript on my Windows XP machine, but my frustration eventually led me to open the exported file manually. Moving "file://" above the term "[UNTRUSTED]" fixed my problem.
  • I need some help to understand the fix:
    I went to NoScrip Options, choose the tab Advanced, choose the Trusted tab, choose the Export option, opened the file in Notepad.
    I cannot find any section [UNTRUSTED]

    Exporting the file under the Untrusted tab provides exactly same text file as the Trusted export.

    How should I proceed? Thanks a lot for your help.
  • On Nov 8 2010, dOggOnit mentionned his hunch of interferring.

    I tried it and uninstalled Microsoft .NET Framework 2.0 Service Pack 2 and now Zotero Notes works perfectly well with NoScript.
  • There are security concerns associated with whitelisting all "file://" URIs. An attacker could deposit a malicious script anywhere on the filesystem and evade NoScript's security.

    Is there any way to narrow down which files or directories that Zotero needs to have whitelisted by NoScript in order to function?
  • What are the security concerns? Even if you whitelist file:// URIs in NoScript, Firefox still won't load a file:// URI from an HTTP URI.

    If you try it yourself, you'll get something like this in the Error Console:
    Security Error: Content at http://example/test.html may not load or link to file:///Users/.../Downloads/test.js.
  • edited August 9, 2012
    I'm no security expert, but an HTTP URI isn't the only mechanism by which someone could be tricked into loading a file:// URI. For example, I can easily see a spear phishing attempt where someone was instructed to paste a file:// URI into their browser. Others will probably come up with something more clever.

    If there are no feasible attack vectors via file:// URIs, why would NoScript filter them by default? Put another way: is it the Zotero project's opinion that NoScript's default scanning of file:// URIs is superfluous?
  • edited August 9, 2012
    I don't think even a pasted file:// URI (or one loaded from a local mail client, if that even works) could do much of anything. Mozilla applies a same-origin policy to file:// URIs, restricting them to files within the same directory as the originating file.*

    I don't know why NoScript blocks file:// by default, but NoScript does exist for more than just security. (As noted on that page, Mozilla's handling of file URIs also changed in 3.0, so NoScript's blocking may predate that.) In any case, we're really just telling people how to make Zotero work with NoScript for people who choose to use both. Whether you're comfortable doing that is up to you.

    Zotero only needs access to its extension directory in the Firefox profile, but I don't think NoScript even allows you to whitelist a subpath of a file:// URI. If you enter a full URI it truncates it to just file://.

    We might be able to load TinyMCE from a resource: URI, which NoScript doesn't block by default, but we'd have to look into whether that's possible.

    * Maybe there's some convoluted potential attack by which you get someone to browse to a website, force the download of an HTML file containing JS, send them an email with a file URI for them to paste in, from that page load a specific file with a known filename from their downloads directory (since you can't list the directory), craft an image URL containing the contents, and add an img tag to the DOM with that URL as the src. Even if all that actually works, I think there are easier and more fruitful attack vectors.
Sign In or Register to comment.