Inner auth() seems to adhere to outer auth() rules - firebase

Question

In our application we use Firebase's custom login functionality to store some metadata in user's auth token.
Later we send this token to one of our web applications to perform a task on behalf of the user using a new admin token to disable security rules. The idea is that a particular location is not writable by authenticated users directly, but data could be written in that location after some server side calculations and validations are done.
Here's a sample code of what I'm trying to do:
var testRef = new Firebase(firebaseApp + 'test');
testRef.auth(userFirebaseAuthToken, function(error, result) {
if (!error) {
var userId = result.auth.userId;
// perform validations and calculations
var tokenGenerator = new FirebaseTokenGenerator(firebaseSecret);
var token = tokenGenerator.createToken({admin: true});
var protectedRef = new Firebase(firebaseApp + '/protected/');
protectedRef.auth(token, function(error) {
if (!error) {
protectedRef.child('foo').push({id: userId});
}
});
}
});
But I get this error:
FIREBASE WARNING: set at /protected/foo/-Ityb1F6_G9ZrGCvMtX- failed: permission_denied
When desired behavior is to be able to write in that location using an admin token.
I understand that this might not be a Firebase issue, but some JavaScript good/bad parts, but what I need to do is to write in some protected location on behalf of a user which even though is not authorized to write in that location, but needs to be authenticated.

Answer 1

Based on what I've seen from my test units and from experience, I don't think that new Firebase actually gives you an independent connection to the data. That is to say, these are both connected to the same Firebase instance internally (I think):
var refA = new Firebase('...');
var refB = new Firebase('...');
So if you want to re-auth, I'm pretty sure you need to call unauth first, which will probably affect your testRef instance as well.
If you truly need to have multiple instances opened to the database with different auth at the same time, then you'll have to look at node-fibers or some other worker pool model, which will allow separate connections.
However, give some thought to this; you are probably overthinking your approach. If you are writing on behalf of a user who doesn't have permissions, then you probably don't actually need to be authenticated as that user.
I've written an entire app with secure Firebase components that are consumed by a third-party app, and then written back to privileged paths and then read by users, and haven't yet run into a condition where the server would need to demote its permissions to do this.
That's not meant to presume I know your use case, just to give you some encouragement to keep things simple, because trying to juggle authentication will not be simple.
My approach is to treat the Firebase security rules as a last defense--like my firewall--rather than part of the programming algorithm used by privileged processes.