* browser-policy uses browser-policy-framing and browser-policy-content, both of
which set default policies when they are used. This way you get a default
policy when you add a browser policy package, but you can pick and choose
different packages if you only want to think about one of them.
* The two packages use different namespaces: BrowserPolicy.framing and
BrowserPolicy.content, which meant some functions got renamed (e.g. not using
"framing" or "content in the function name when it's already in the
namespace).
- Remove starter-browser-policy and replace it with
BrowserPolicy.enableContentSecurityPolicy(), which gives you the starter
policy and allows you to use the other BrowserPolicy functions to configure
it. This is motivated by the fact that the API isn't very intuitive without a
well-defined starting policy. ex: if the package starts off without a policy,
and then the user calls allowAllContentSameOrigin(), that will result in
turning off inline scripts, which is probably not what they wanted.
- AllContent functions do more of what you'd expect now;
i.e. BrowserPolicy.disallowAllContent() actually disallows all content,
instead of setting default-src to 'none', which will allow other types of
content that have previously had srcs set for them.
- Add some tests
This means node's crypto.randomBytes on the server, and
window.crypto.getRandomValues on the client. If node's crypto.randomBytes throws
an exception, we fall back to crypto.pseudoRandomBytes. If
window.crypto.getRandomValues isn't supported by the browser, we fall back to
the alea generator that we had been using previously.
As part of a docs pass we will explain the new way to use coffeescript globals.
(In short: in a package, anything declared with `api.export` becomes
package-level and exported. If you want something package-level and not
exported, or app-level, there's an object `share` and you can assign to fields
on it.)
This code depends on PR 680. In addition, the docs include a link to
the proposed AppCache wiki page.
Adds the appcache smart package and associated documentation.
QA notes are in packages/appcache/QA.md (Is this a good place to put
them?)
Meteor's sass package wraps the "sass" NPM module, which implements a version of
the Sass language much older than the .sass described at sass-lang.com (and
doesn't implement the current recommended .scss language at all). It also has
poor error handling, so it mostly just ends up confusing users.
The module is unmaintained, and its author now uses stylus/nib (which Meteor
supports: see the stylus package).
If many users want Sass support, we could add this back in wrapping the
"node-sass" package instead (which supports a more recent version of the Sass
language), but for now, just remove it. Meteor still supports Stylus and Less
out of the box.
Fixes#143.
sass.js implements a version of Sass much older than the .sass (let alone
currently recommended .scss) described at sass-lang.com, and has poor error
handling so it mostly just ends up confusing users. sass.js's author now uses
stylus/nib. We should probably remove the sass package, but let's not add
another breaking change to 0.5.0.
