1.20.0 (2023-01-25)

Features

• state: Base64 encoding instead of uri encoding of state param for yahoo (#658) (b196a7b)

1.19.5 (2021-09-19)

Bug Fixes

• redirects: lock down redirect attempts, fixes #619 (544e5ea)

1.19.4 (2021-06-24)

Bug Fixes

• lint: lint and publish #622 (c3988b6)

1.19.3 (2021-04-13)

Bug Fixes

• deps: npm audit localhost (384bf14)

1.19.2 (2021-03-20)

Bug Fixes

• ci: build dist (e9be935)

1.19.1 (2021-03-20)

Bug Fixes

• ci: build dist (8b56eb5)

1.19.0 (2021-03-20)

Bug Fixes

• global: remove global variable (2c378fe)

Features

• build: build dist from bash (29ee7a4)

Performance Improvements

• remove redundant files from published npm package (816cbb3)

Fix(xss): vulnerability

See related issue #529

• New Module Spotify #524
• Add Popup options left and right #500
• Add params to oauth_proxy #528

Fixes Facebook auth login version parameters. See #498

See #494

#448

Remove authentication 'display' parameter by default

Fix #406

v1.12.0 reverts the default scopes that were introduced in v1.11.x

Now there is only one standard scope...

• basic: "" (empty string)

In this release modules must explicitly define empty strings for common scopes. Not sure what that means? Let me explain.

So if you we have a generic function like which calls hello.login with the scope 'email' (a standard scope in hellojs v1.11), like so...

login(network) => hello(network).login({scope.email});

Now lets say that all but one of the providers linked to this service supported the email scope. The one that didn't is the one we are worrying about.

• In v1.11.x: The module for network which doesn't support the scope 'email' would not have to worry, because it was a standard scope which defaulted to an empty string and it would not be applied to the OAuth login request. Conversely if the others supported the email string they would have to explicitly define it. email: 'email'.
• In this version v1.12.0: Its changed instead the module must explicitly say that it doesn't support that scope. i.e.

scope: {
    email: ''
}

Typically its left up to the person implementing the library to know which scopes the provider supports But in the case of the the bundled modules its nice to map the scopes to an empty string to help the developer out. Doing it this way does involves more configuration (arguably), setting common scopes to an empty string, but on the flip side if they support the common scope then they dont have to set laboriously map the value to itself, with email: 'email'.

The real benefit comes with creating new modules. Developers dont need to know about this secret standards list which HelloJS has applied. So they can use any scope without having to wonder why its not been applied.

I hope that makes sense.

Thanks

Scope Map

This changes how default scopes are mapped. Previously a default scope was defined by what other modules had defined. This was particulary bad behaviour as depending on your modules a scope was deemed a default of "" (an empty string) was applied.

However this could still break some services. The following scopes will be mapped to null unless otherwise stated.

• basic
• email
• files
• friends
• photos
• publish
• publish_files
• share
• video

Phonegap

The phonegap specific code has been removed from hello.js, and included with hello.phonegap.js (this is still bundled with dist/ files)
The OAuth flow is much better now, with less webviews being opened and closed. However you might like to revert to the previous version if you have problems.

Fix #362 #361 #357 #360 #359 #354