MozillaZine

Links to local pages do not work

From MozillaZine Knowledge Base

Note: The ability to open local file links using the methods listed in this article has been removed in Firefox 29 (see bug 995943, fixed in Firefox 30). For more information see Site Compatibility for Firefox 29 - Security (MDN). Related discussion here and in this Mozilla Support thread.


For security purposes, Mozilla applications block links to local files (and directories) from remote files. This includes linking to files on your hard drive, on mapped network drives, and accessible via Uniform Naming Convention (UNC) paths. This prevents a number of unpleasant possibilities, including:

  • Allowing sites to detect your operating system by checking default installation paths
  • Allowing sites to exploit system vulnerabilities (e.g., C:\con\con in Windows 95/98)
  • Allowing sites to detect browser preferences or read sensitive data

Unless you use one of the following workarounds, the blocked hyperlink simply will not work.

No error dialog, security warning, or other user-visible notification will be displayed, except for an entry in the (JavaScript) Error Console (bug 84128, bug 122022).

Contents

[edit]

Using an Extension

[edit]

LocalLink

The LocalLink extension allows overriding the security check per click: links to local pages can be followed using the context menu for the link.

[edit]

IE Tab

The IETab extension allows you to open Firefox tabs with IE content. Since IE is able to browse local file systems, this can be used to open local links.

You can even use "Open Link in Ext.App." from the context menu to open a real Windows Explorer window.

[edit]

Disabling the Security Check

If you are willing to accept the possible risk of linking to local content, you can override the security policy.

Note: If you are using the NoScript extension, the user_pref approach as described below does not work, NoScript overrules the checkloaduri configuration. Instead, it is possible to allow local links (file://) in your NoScript Options ("Advanced -> Trusted -> "Allow local links").

[edit]

Firefox 1.5, SeaMonkey 1.0 and newer

In the most recent versions of these browsers, the old global preference has been removed. Instead, the checkloaduri preference has been combined with the CAPS interface so you can change the setting on a per-site basis with Security Policies. For example, to allow a certain domain to bypass the checkloaduri restriction, this could be added to user.js or prefs.js: 

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "http://www.example.com");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

The line with capability.policy.localfilelinks.sites can have multiple websites separated by spaces, like so: 

user_pref("capability.policy.localfilelinks.sites","http://www.example.com http://www.example.net");

(Naturally, you would replace http://www.example.com and http://www.example.net with sites you wanted to allow access.)

Site names must be listed as in the above example: the protocol (http://) followed by the domain name (www.example.com) followed by, if necessary, a port number (:8080). They should not include the final / or anything else from the path part of the URL.

[edit]

Thunderbird 1.5, SeaMonkey 1.0 and newer

To enable opening file links you receive in e-mails, follow the example for Firefox 1.5, but with the user.js file in your Thunderbird profile. In the capability.policy.localfilelinks.sites entry, for POP3 enter mailbox://mail.example.com, or for mail on your system, simply mailbox://. For IMAP, use imap://mail.example.com. You may need to include your username or the port number. Something like (for IMAP): 

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites","imap://username@mail.example.com:143");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

or, for POP mail: 

user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites","mailbox://");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");


If it's not working, turn on the (JavaScript) Error Console, click a link in an email, and look at the error message. It will tell you what path it's trying to access. Enter the first part of that path, up to and including the port number, in the capability.policy.localfilelinks.sites pref. Note that [1] implies that a rule with protocol mailbox: should allow mail in your pop3 mailbox to contain file: links, however it seems necessary to include in the rule the hierarchical symbol: mailbox://.


[edit]

Path Syntax

You also need to use proper URI syntax for local file references. It is not proper to enter an operating-system-specific path, such as c:\subdir\file.ext without converting it to a URI, which in this case would be file:///c:/subdir/file.ext. In general, a file path is converted to a URI by adding the scheme identifier file:, then three forward slashes (representing an empty authority or host segment), then the path with all backslashes converted to forward slashes.


[edit]

UNC Paths

If you're linking to a file in a UNC path (e.g., \\servername\share\file.ext), you will need to specify the path thusly: 

file://///servername/share/file.ext

Also note that you cannot link to file://///servername to get a listing of shares at that hostname due to a bug.

[edit]

See also

[edit]

External links

[edit]

Related bug reports

Retrieved from "http://kb.mozillazine.org/Links_to_local_pages_do_not_work"