User-Agent: Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.7) Gecko/20040616 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; hu-HU; rv:1.7) Gecko/20040616 user_pref("capability.policy.allowclipboard.sites", "http://alex.wps.intra.net"); That configuration should allow specifying a "*" host or something, because someone wants to enable the editor everywhere. (We develop a CMS, and we need to run the editor on hundreds of domains.) Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: You can only specify specific host name or maybe host names (which is not mentioned on the help page). Expected Results: Specify a wildcard to allow all sites in a domain or all sites all around the world. I've tried "*" and removing the line too, none of them allowed the one site I am testing the editor with.
Assignee: mozeditor → dveditz
Component: Editor: Core → Security: CAPS
QA Contact: bugzilla
http://www.mozilla.org/projects/security/components/ConfigPolicy.html is more relevant documentation than http://www.mozilla.org/editor/midasdemo/securityprefs.html.
This too is a feature that would be very useful on institutional intranets. See http://enterprisefirefox.org for more info.
Granting capabilities by path ignoring the domain as the original submitter seem to suggest is a very bad idea, as everyone everywhere (e.g. on evilhackers.org) could fake your path structure and be abusively granted. On the other hand, you can already specify policies including a domain *and its subdomains* with no wildcards. If you specify "google.com", your policy applies to "www.google.com" and "pages.google.com" as well. One minor caveat: because of a CAPS parser glitch, if you specify a second level domain (such as the google.com above), in order to include sites in the bare 2nd level domain itself (i.e. no www), you must add them using full addresses, so your policy sites preference must look like: user_pref("capability.policy.allowclipboard.sites", "http://google.com", "https://google.com", "google.com"); The same goes for addresses with a non-standard port, which need to be specified in full form. The NoScript extension, which largely uses CAPS undercover, does mask these inconveniences and even "emulates" wildcards (or, to be precise, shortcuts) for multiple ports and numeric subnets, see http://noscript.net/features#sitematching Talking about NoScript, a more granular "custom permissions" system is in the works and will be added to the current simple, easy but draconian trusted/unknown/untrusted approach. This will further mask and wrap CAPS details and plugin blocking in a way that will let user specify, for instance, that in a certain site he wants JS, JS clipboard access, Java but not Flash and other plugins, or in another site he wants JS but not JS clipboard access/plugins, and so on.
You need to log in before you can comment on or make changes to this bug.