Note: we are doing a minor bump facebook rather than a major bump, even
though this is arguably backward-incompatible. But it's only reflecting
a backwards-incompatible change to reality, and we expect the upgrader
text to do a better job of expressing compatibility concerns than the
version number. There's no reason to make Atmosphere packages that
depend on facebook republish, as they are unlikely to need any changes
anyway (mostly, apps may).
Facebook is making a change on April 30th: all users of the previous
unversioned Facebook API will automatically start using the 2.0 API, and
the 1.0 API will be unavailable. By upgrading your Meteor to include
this commit, you will be able to start adapting your app to the post-1.0
world now rather than next month.
Full information about the changes to Facebook's APIs can be found at
https://developers.facebook.com/docs/apps/upgrading
If you only use Facebook integration for login via accounts-facebook,
and don't use users' access tokens to access the Facebook API on their
behalf, then the only changes you are likely to observe are:
- The `id` returned by Facebook for users who had not previously used
your app will be an "app-scoped ID". You cannot use these to directly
correlate users between multiple apps (without using the Business
Mapping API). This does not affect users who have already logged in
to your app, so they will continue to be able to access your app.
- Meteor asks for the `email` permission by default, and copies the
`email` field from the `/me` object into the `serviceData.facebook`
field on `Meteor.user()`, along with other fields which only require
the `public_profile` permission. With 2.0, users can decline to grant
all permissions other than `public_profile`, which means that you
might not get their `email` address. You can use the `/me/permissions`
API to tell if permissions were declined.
Additionally, if you are accessing other Facebook APIs using the
`access_token` returned via login, you should be aware that some
permissions have changed in Facebook Graph API 2.0 and newer. Most
notably, many operations involving friends need permissions such as
`user_friends` to be explicitly requested now. Users can decline any
permission (other than `public_profile`). Apps which need permissions
other than `public_profile`, `email`, and `user_friends` may need to
pass through a review stage before being fully activated.
To change your app to request new permissions such as `user_friends`,
specify the `requestPermissions` option to
`Meteor.loginWithFacebook` (if you implemented your own login UI) or to
`Accounts.ui.config` (if you are using the `accounts-ui` package).
Note that while Meteor will now always use the v2.2 API to fetch the
access token, it does appear that the access token can still be used to
access pre-v2.2 APIs. For example, you can still use the access token
to run FQL queries, even though FQL was removed in API v2.1.
Fixes#3123.
It used to create a directory with an underscore instead of a colon
Now, it just removes the prefix.
In cases where the name of the package has more than one colon or starts or ends
witha colon, we report an error.
In particular, ban leading `-`, trailing `.`, and `..` anywhere.
This backport commit drops the changes to constraint-solver and adds a
History.md note.
The blaze package defines Blaze.Template, not Template, and should find
it there.
(Apps tend to put `Template = Blaze.Template` globally on the client via
templating package, but that's not guaranteed, and doesn't happen on the
server.)
This reverts commit 5d3cfa2d76, reversing
changes made to 2b466a9015.
Ah well, we tried to enable websocket compression again and ran into
more bugs.
First, newer versions of websocket-driver seem to sometimes send
duplicate close messages:
https://github.com/faye/faye-websocket-node/issues/41
This occurs whether or not deflate is actually used.
Second, in some circumstances permessage-deflate seems to completely
corrupt messages. This was reasonably easily observable by running
test-packages with Chrome, and seeing that sometimes (but not always) a
large number of bad JSON messages got printed to the client
console. (Another symptom was that the total number of tests would be
larger than it should be, leading to messages like "Passed 1109 of
1153", presumably because the test name got corrupted in some status
messages.) https://github.com/faye/permessage-deflate-node/issues/4
See #3007.
For example, 5ddf203 stops us from understanding $sets and $unsets with
empty field parts, but pre-2.6 MongoDB could generate them. (And even
post-2.6 may be able to generate $unsets with bad field names, but it's
not important for us to match that behavior since with Minimongo you
shouldn't be able to put them in in the first place.)
Projection functions act on *documents*, not the diffs that are passed
to changed callbacks. For example, a projection `{'a.b': 1}` applied to
the *document* `{a: undefined}` will result in `{}`, but the *diff*
of `{a: undefined}` on a query with that projection should still result
in a `changed` callback with that diff being invoked.
Refactor various parts of minimongo to always have a projectionFn for
each observed query (perhaps a trivial one).
Pass the projection into _diffQueryChanges so that it can apply the
projection *before* taking the diff, in the two cases in Minimongo which
use _diffQueryChanges instead of direct application. (We could instead
make the query's results and resultsSnapshot be projected, but Minimongo
currently relies on the fact that these data structures alias the
documents stored in the collection.)
Stop applying the projection to the diffs in changed via
wrapCallback. (We could still use wrapCallback to apply the projection
for added/addedBefore calls, but it seems more consistent to use the
same mechanisms for added that we use for changed.
Fixes#3800. Fixes#2254. Fixes#3571.
This change actually introduces another layer of projections before diffing, in
addition to more projection after the diffing, on the result.
I didn't figure out why, but the tests fail if you remove either of them.
Adds tests. Fixes#2254.
Specifically, Mongo.Collection objects on the server now have
rawCollection and rawDatabase methods.
You can use MongoInternals.NpmModules.mongodb.version to tell what
version of the mongodb npm module is the backend for HTTP.call. This
version may change incompatibly from version to version of Meteor; use
at your own risk. (For example, we expect to upgrade from the 1.4.x
series to the 2.x series in the not-too-distant future.)
Fixes#3640.
