Support multiple Auth's to the same Firebase and extend Authentication Options for JWTs

[deldrid1]

It looks like there are some compatibility issues with the latest node-red. I'm guessing this has to do with
- all of our hacks around dealing with "All Firebase references to the same database share the same authentication status"
- the fact that there is no way to enforce a singleton authentication in Node-RED
- Some of the changes to scope of config nodes

The Firebase references sharing auth has been a problem with these nodes for some time, there is no way to grab data that spans across multiple accounts that you can access unless you have access to an admin account that can access both of them.

According to this Google Group, it looks like there may now be an undocumented way to get this to work! It looks like the magic is a second arbirtrary argument (the node-id?) to new Firebase:

var ref1 = new Firebase(url, "foo");
var ref2 = new Firebase(url, "bar");

And that's really it. The second parameter to new Firebase is a context,
which can be any arbitrary non-empty string. You can separately
authenticate ref1 and ref2 above, at the same time, using different
authentication providers. Note that for every new context, you create a new
concurrent user. This is important since while most clients use the same
websocket for all data regardless of how many times you call new
Firebase (meaning
they only count as one concurrent), passing a context will open up a new
websocket (and thus count as an extra concurrent).

Look into implementing this, upgrading to the latest libraries, potentially add some flexibility to the Master Token auth method to allow passing in more arguments, and get everything up and running on the latest node-red (really the way that it always should have been)

[deldrid1]

On the Master Token Auth we could also expose the options that are exposed as the second argument to FirebaseTokenGenerator as nice checkboxes, datepickers, etc.:

• expires (Number) - A timestamp (as number of seconds since the epoch) denoting the time
  after which this token should no longer be valid.
• notBefore (Number) - A timestamp (as number of seconds since the epoch) denoting the time
  before which this token should be rejected by the server.
• admin (Boolean) - Set to true if you want to disable all security rules for this client.
  This will provide the client with read and write access to your entire Firebase.
• debug (Boolean) - Set to true to enable debug output from your security rules. This
  debug output will be automatically output to the JavaScript console. You should generally
  not leave this set to true in production (as it slows down the rules implementation and
  gives your users visibility into your rules), but it can be helpful for debugging.

Here is an example of how to use the second options argument:

var FirebaseTokenGenerator = require("firebase-token-generator");
var tokenGenerator = new FirebaseTokenGenerator("<YOUR_FIREBASE_SECRET>");
var token = tokenGenerator.createToken(
  {uid: "1", some: "arbitrary", data: "here"},
  {admin: true}
);

If you know how Firebase JWT's are built, you can do these yourself but it would be nice to simply include the options in Node-RED.

[deldrid1]

Most of the first comments were taken care of in 1.0.0. However, this ticket will stay open until I get around to the second comments

[ssoleman]

In addition to extending authentication options for JWT's, there needs to be code added to reject certain inputs for additional tokens that are not allowed according to the firebase documentation see https://firebase.google.com/docs/auth/admin/create-custom-tokens