Add Misc Header and Auth support

[BerkeleyTrue]

This adds support for authorization and misc headers.
Misc Headers can be added in the remote connector settings
in client/datasource.json.
Authorization happens automatically using local/session storage.
While headers are tested and working, authorization requires
two other PRs to work.

1. Loopback needs to use User.remoteMethod instead of
   loopback.remoteMethod in common/models/user.js
   see Use User.remoteMethod instead of loopbacks method loopback#943
2. Strong-Remoting needs to support hooks when
   using http.prototype.invoke
   see Add remote hooks to restAdapter.invoke method strong-remoting#152

See strongloop/strong-remoting#105

[BerkeleyTrue]

Any feedback on this?

[bajtos]

Hey @BerkeleyTrue, sorry for not responding sooner. We use waffle.io to track PRs across all loopback-related repositories and it seems that the integration was recently :(

@ritch @kraman I think you two are best suited to review the patch, PTAL.

[bajtos]

@BerkeleyTrue please rebase the patch on top of the current master (see #10).

[BerkeleyTrue]

@bajtos Done

[ritch]

Stray comma

[BerkeleyTrue]

@ritch Setting headers using remote hook.

[ritch]

Need to remove the opinionated User.login / logout hooks before merging this.

[ritch]

I don't think storage belongs in this module. All we need to do in the connector itself is ensure the token and any other metadata required by authentication is set on the context and or request.

Everything else is really outside the domain of this module. I think it actually belongs in the LoopBack AccessToken or User models.

I think we just need something like this in the connector itself:

// the dataSource
var remote = loopback.createDataSource();

// set the accessToken to be sent along with each request / invocation
remote.setAccessToken(accessToken);

// or set the accessToken during creation (the Connector would just call `remote.setAccessToken()`)
var remote = loopback.createDataSource({
  connector: 'remote',
  url: 'http://localhost:3000/api',
  accessToken: accessToken
});

@bajtos @kraman @BerkeleyTrue

[bajtos]

I don't think storage belongs in this module. All we need to do in the connector itself is ensure the token and any other metadata required by authentication is set on the context and or request.

I agree that browser-specific stuff should be left out of this pull request.

@ritch your proposal may be putting too much burden on the users of this module. So we may end up with including some part of the browser storage in the connector itself. However, even if that happens, then it should be build on top of the non-browser-specific API provided by this PR.

Here is my proposal:

• In this PR, implement the API proposed by @ritch above
• Once it is landed, look into ways how to persist and restore the access token in the browser.

[bajtos]

@ritch is this patch still relevant after strongloop/strong-remoting#181 was landed in strong-remoting?

[slnode]

Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test."

[bajtos]

@slnode ok to test

[bajtos]

@ritch @BerkeleyTrue I think this patch is no longer relevant, see strongloop/strong-remoting#105 (comment)

Code snippet showing how to configure authentication:

app.dataSources.remote.connector.remotes.auth = {
  bearer: new Buffer(token).toString('base64'),
  sendImmediately: true
};

[ritch]

Closing this for now. If we want to add miscellaneous header support let's create an issue to track that.