Last Comment Bug 253743 - capability.policy..sites should allow wildcards for hostnames
: capability.policy..sites should allow wildcards for hostnames
Status: NEW
Product: Core
Classification: Components
Component: Security: CAPS (show other bugs)
: Trunk
: x86 Linux
-- normal with 3 votes (vote)
: ---
Assigned To: Daniel Veditz [:dveditz]
: Selena Deckelmann :selenamarie :selena use ni?
Depends on:
  Show dependency treegraph
Reported: 2004-07-30 10:23 PDT by Ferenc Veres
Modified: 2009-08-23 14:28 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Ferenc Veres 2004-07-30 10:23:36 PDT
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", "");

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:

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.
Comment 2 User image Yuriy Krylov 2007-09-19 20:19:27 PDT
This too is a feature that would be very useful on institutional intranets. See for more info.
Comment 3 User image Giorgio Maone [:mao] 2007-09-20 00:31:17 PDT
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 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 "", your policy applies to "" and "" as well.

One minor caveat: because of a CAPS parser glitch, if you specify a second level domain (such as the 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:
"", "", "");

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

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.

Note You need to log in before you can comment on or make changes to this bug.