Frequently asked questions

The following notes answer common questions, and may be useful to you when installing, configuring or using django-flashpolicies.

Why do I need a cross-domain policy file?

Much like JavaScript, the Adobe Flash player by default has a same-origin policy; a Flash player instance on one domain cannot load data from another domain.

A cross-domain policy file allows you, as the owner of a domain, to specify exceptions to this, allowing loading of data from another domain (for example, if you have data hosted on a CDN).

In order to prevent security issues caused by loading data from untrusted domains, your cross-domain policy file should permit only those domains you know are trustworthy (i.e., because those domains are under your control, and you can prevent malicious content from being placed on them).

Why doesn’t this application generate Silverlight’s format?

The Microsoft Silverlight plugin has a same-origin sandbox like Flash, and its native format for cross-domain policies is a file called clientaccesspolicy.xml. However, if clientaccesspolicy.xml is not found on the target domain, or otherwise returns an error, Silverlight will fall back to requesting and obeying a Flash crossdomain.xml file.

This means that a single file – crossdomain.xml in the Flash format – suffices for both Flash and Silverlight. Additionally, Silverlight is no longer supported in current versions of Microsoft’s own Edge browser, support for it is in the process of being dropped/disabled in other major browsers, and Microsoft has announced that Silverlight will reach end-of-life in 2021, meaning that the Silverlight-only format corresponds to an already-small and shrinking, and soon to be nonexistent, supported base.

Why are the elements in a different order each time I serialize my policy?

Internally, a Policy stores information about permitted domains and headers in dictionaries, keyed by domain names. The resulting XML is generated by iterating over these dictionaries.

The order of keys emitted when iterating over a dictionary is something which has changed multiple times in different versions of Python. If you see inconsistent order, this is not a bug; it just indicates the dictionary-iterating behavior of the version of Python you’re using. This also does not affect the well-formedness or validity of the resulting XML document.

Why shouldn’t I use wild-card (‘*’) domains in my policy?

Use of wild-card entries in a policy effectively negates much of the security gain that comes from explicitly specifying the permitted domains. Unless you can and do vigilantly control all possible domains/subdomains matching a wild-card entry, use of one will expose you to the possibility of loading malicious content.

How am I allowed to use this library?

django-flashpolicies is distributed under a three-clause BSD license. This is an open-source license which grants you broad freedom to use, redistribute, modify and distribute modified versions of django-flashpolicies. For details, see the file LICENSE in the source distribution of django-flashpolicies.

What versions of Django and Python are supported?

As of django-flashpolicies 1.14, Django 3.2 and 4.0 are supported, on Python 3.7 (Django 3.2 only), 3.8, 3.9, and 3.10. Note that Django 3.2’s support for Python 3.10 was added in Django 3.2.9, so you may experience issues with Python 3.10 and earlier Django 3.2 versions.

I found a bug or want to make an improvement!

The canonical development repository for django-flashpolicies is online at <https://github.com/ubernostrum/django-flashpolicies>. Issues and pull requests can both be filed there.