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.
These were broken by the Template.foo.bar -> Template.foo.helpers({ bar:
... }) transformation. `fields` is a property on the template object,
not a helper.
UIWebView which aren't able to use the preferred "popup" login flow.
See the specs for details:
https://meteor.hackpad.com/OAuth-redirect-flow-spec-PeziTcaNPDPhttps://meteor.hackpad.com/OAuth-redirect-flow-part-II-vswwUKP4vXe
I extracted code to construct a URL from the `http` package into a new
`url` utility package. The new package has no public API, it simply
has the original URL construction functions that were in `http` and
makes them available to oauth.
Fixes the Meetup account login, as Meetup now requires using
"https://api.meetup.com/2/members" instead of
"https://secure.meetup.com/2/members".
The `?close` parameter for the redirect URI is now not needed or used.
For backwards compatibility the `?close` parameter is included if the
login service configuration doesn't include the `loginStyle` field
(indicating it was created using old code).
Addresses #2048.
An earlier attempt (to wait for the config to load) ran into popup
blockers.
It would be nice to load the config statically with something like
Arunoda's fast-render. That said, even that's not good enough to allow
OAuth logins that bypass the popup blocker that aren't a result of a
user action, and for user actions it's easy enough to gate your login
button on `Accounts.loginServicesConfigured()`.
Longer term solutions include non-popup methods of OAuth login (see
Issue #438).
While this could mean that there's an indefinite wait before logging you
in, any condition where login configuration isn't being swiftly
published (after all, it should be cached) is a bigger problem.
`Accounts`/accounts-base is an awkward place to put this, because in
theory we wanted the packages like "twitter" to not depend on
accounts. But it turns out that service-configuration depends on
accounts anyway, so this isn't much of a regression. We can't put this
function in service-configuration because that package doesn't actually
do the subscription and make the ready handle. (Maybe oauth would be a
better place, but again, that's a package that doesn't currently depend
directly on accounts-base and would have to.)
Fixes#1911 and #2048.
Have `OAuthEncryption.open` throw "decryption unsuccessful" on any
error to avoid allowing an attacker to break the encryption key by
observing the result of sending manipulated ciphertexts.
Add oauth-encryption and the oauthSecretKey config options to the docs
page.
Update history.
More documentation on functions.
Use `OAuth.sealSecret(...)` instead of `{seal: ...}`.
Rename OAuth._openSecret(s) to OAuth.openSecret(s).
In the readme describing how to generate a key, just use Node instead
of going through the hassle of creating a Meteor application.
Have the `oauth` package weakly depend on `oauth-encryption` for when
it's being used without accounts.
Add tips on using oauth-encryption without accounts to the readme.
database.
"Oauth" is renamed to "OAuth". "Oauth" is kept as an alias for
backwards compatibility.
README.md contains a sample description of how to generate and use the
oauthSecretKey, which might be incorporated into the wiki
documentation page.
