Closed Bug 253743 Opened 20 years ago Closed 3 years ago

capability.policy..sites should allow wildcards for hostnames

Categories

(Core :: Security: CAPS, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: lion, Assigned: dveditz)

References

()

Details

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.
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
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.
QA Contact: caps

I think that setting does not even exist nowadays. I'll close this with INVALID (by now).

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.