The default bug view has changed. See this FAQ.

capability.policy..sites should allow wildcards for hostnames

NEW
Assigned to

Status

()

Core
Security: CAPS
13 years ago
8 years ago

People

(Reporter: Ferenc Veres, Assigned: dveditz)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

13 years ago
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.

Updated

13 years ago
Assignee: mozeditor → dveditz
Component: Editor: Core → Security: CAPS
QA Contact: bugzilla

Comment 1

12 years ago
http://www.mozilla.org/projects/security/components/ConfigPolicy.html is more
relevant documentation than
http://www.mozilla.org/editor/midasdemo/securityprefs.html.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Midas copy/paste config should accept more hosts in allowclipboard → capability.policy..sites should allow wildcards for hostnames

Comment 2

10 years ago
This too is a feature that would be very useful on institutional intranets. See http://enterprisefirefox.org for more info.

Comment 3

10 years ago
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.
QA Contact: caps
You need to log in before you can comment on or make changes to this bug.