User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:220.127.116.11) Gecko/20110303 Firefox/3.6.15 by Peacy (.NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:18.104.22.168) Gecko/20110303 Firefox/3.6.15 (.NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729) When the Reproducible: Always Steps to Reproduce: 1. Edit the CAPS policy (eg. localfilelinks): user_pref("capability.policy.policynames", "localfilelinks"); user_pref("capability.policy.localfilelinks.sites", "mydomain.com"); user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess"); 2. Configure the web-server to use non-standard TCP port 2. On the webserver server.mydomain.com create a test HTML file with the filelink to the UNC path, eg: file://///server/share/filename.txt 3. access the test file, adding the port information server.mydomain.com:tcpport/testfile.html Actual Results: Opening of the file link fails Expected Results: Links in approved domain should be openen regardless of TCP port
Could you please provide a link to a test server which displays this bug? We likely won't be able to investigate this issue otherwise.
The example is missing protocol scheme and port. The correct format is: user_pref("capability.policy.localfilelinks.sites", "http://server.mydomain.com:8080"); http://kb.mozillazine.org/Links_to_local_pages_don%27t_work " 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. "
Is this INVALID/WONTFIX based on comment 2? I defer to a developer on the Security team to decide.
The syntax user_pref("capability.policy.localfilelinks.sites", "mydomain.com"); works properly for the whole domain. As I have many hundreds of web servers, it is not reasonable to add single entries. The examples I have do refer to the Intranet system only, but I believe the test case is easy to reproduce.
You need to log in before you can comment on or make changes to this bug.