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.
