Implement auth support about angularfire

[petebacondarwin]

Yes, I agree. I was recently looking at
https://github.com/Zenovations/FirebaseIndex and thought it would be nice
to bind to one of those too.
Pete

On 11 April 2013 18:02, Anant Narayanan [email protected] wrote:

The angularFire constructor only takes a URL as an argument, which makes
auth more difficult than it should be. Like Backfire, we should accept
Firebase objects that could be pre-authed, in addition to URLs.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12
.

[jaredwilli]

It would be so nice to have this added. I've been drilling my head into walls trying to just make firebase, and firebaseAuthClient work as one within angular, and I gotta say the separation of these the way they are is a pain.

[lifeisfoo]

This works but I think there is a better angular way to do auth

return function(collectionUrl, token, initialCb) {
    var collection = [];
    var indexes = {};
    var collectionRef = new Firebase(collectionUrl);
if(token != null){                                                                       
      collectionRef.auth(token, function(err){throw err;});
}    

[lifeisfoo]

@anantn I have different application in the same page and a shared pre authed Firebase is the correct solution.
Furthermore (since there are many auth methods) supporting auth externally will keep this lib small and easy to use.

[anantn]

Thanks for the feedback @lifeisfoo - the best thing might be to support both pre-authed Firebase as well as in-built authentication to cover all user cases - thoughts?

[lifeisfoo]

Yes, both are useful, but I think that pre-authed FB support can be implemented much faster than the internal auth support. The two methods can be released separately (just for a sooner release).

[zgohr]

+1 for internal Firebase auth, but I would be fine if the ref was simply accessible on the angularFire service so I could handle auth separately. I'm new to Firebase so I apologize if this isn't a real solution.

[anantn]

@lifeisfoo, @zgohr - with commit b44ec16 you can now pass a ref directly to angularFire (and pre-auth it if you'd like) - for example

function MyCtrl($scope, angularFire) {
  var ref = new Firebase("<foo>.firebasio.com");
  var auth = new FirebaseAuthClient(ref, function(user, err) {
    if (!err && user) {
      angularFire(ref, $scope, "test");
    }
  });
  auth.login("persona");
}

[lifeisfoo]

I'm already using it :) Thank you.

[jaredwilli]

@anantn I wish I had seen your commit on Friday cause I was just finishing up some things with what I have done to add auth support to it and then I saw your comment. I went about it entirely differently but yours is probably the better way to do it since it's usage is more straightforward.

I basically just created a new service which contains the basic code for FirebaseAuthClient or authToken if exists. For what it's worth, I tried. I have committed my version under a separate branch of my fork here if you're interested in checking it out, and here's the accompanying service I made which makes uses it.

[pmoelgaard]

First... this is my first post here, so let me entirely out of context point out that this is amazing work ! Thanks !
Second... I was trying to use commit b44ec16 but it fails with "Type Mismatch", however the call-stack takes me into some really hairy parts of Firebase.js (at least for my old tired eyes) so I have not much idea what is failing.

My code looks like this, if someone spots an obvious mistake, I would be happy to be corrected:

    var firebase = new Firebase("https://nexoes-threesixty.firebaseio.com/tasks");

    var firebaseAuth = new FirebaseAuthClient(firebase, function (error, user) {
        if (!error && user) {
            angularFire(firebase, $scope, "tasks");
        }
    });

    firebaseAuth.login("persona");

UPDATE:
Having reverted back to the stable version and disengaging authentication, I got the same error, however I see now that the problem was in line 55, the check for type alignment between RET and VAL.
It turns out I was expecting to receive an Array, however instead it was an object (4th arg) here:

Wrong:

angularFire(firebase, $scope, "tasks");
angularFire(firebase, $scope, "tasks", []);

Right:

angularFire(firebase, $scope, "tasks", {});

...this means that it's not an issue with angularFire, however more related to my understanding of Angular... apologies for the "noise" (I'm just so tremendously excited about the prospects for this its hard to keep the arms at programming and not in the air of pure excitement) !

Now, if someone on top of their head can tell me why I with a reference to the tasks in my firebase, is receiving an object, and not an array, then I would be willing to buy that person a 1) beer, 2) coffee, 3) [insert name of your favorite refreshment], at first given opportunity...

[katowulf]

@pmoelgaard I think that probably needs to go into it's own issue (it should probably reference this issue using #12, rather than being included in the discussion thread).

Some details that might help as well: copy/paste the call stack (I know it's long and hairy but someone else spot see something that triggers an idea), what's the output of error in your example above? If you use http://static.firebase.com/v0/firebase-debug.js instead of firebase.js, do you see any additional clues? Does it help with the stack trace?

[pmoelgaard]

Here is the Stack Trace when running it with the square brackets in 4th argument and using the debug edition...

AngularFire.log (angularFire.js:71)
(anonymous function) (angularFire.js:55)
fb.core.view.EventQueue.raiseEvent (firebase-debug.js:5997)
fb.core.view.EventQueue.raiseQueuedEvents (firebase-debug.js:5988)
fb.core.view.ViewBase.raiseQueuedEvents (firebase-debug.js:6095)
(anonymous function) (firebase-debug.js:6761)
fb.core.util.CountedSet.each (firebase-debug.js:4643)
(anonymous function) (firebase-debug.js:6760)
fb.core.util.Tree.forEachDescendant (firebase-debug.js:1212)
fb.core.ViewManager.raiseQueuedEvents (firebase-debug.js:6757)
fb.core.ViewManager.raiseEventsForChange (firebase-debug.js:6753)
fb.core.Repo.onDataUpdate_ (firebase-debug.js:7070)
fb.core.PersistentConnection.onDataPush_ (firebase-debug.js:5578)
fb.core.PersistentConnection.onDataMessage_ (firebase-debug.js:5570)
fb.realtime.Connection.onDataMessage_ (firebase-debug.js:5211)
fb.realtime.Connection.onMessageReceived_ (firebase-debug.js:5206)
(anonymous function) (firebase-debug.js:5142)
fb.realtime.polling.PacketReceiver.handleResponse (firebase-debug.js:3910)
fb.core.util.executeWhenDOMReady.urlParams (firebase-debug.js:4747)
pRTLPCB (.lp:5)
(anonymous function) (.lp:1)_

UPDATE:
When positioning a breakpoint in line 55 of angularFire.js, I can see that we have the following variables which triggers the mismatch:

RET

Array[0]
length: 0
proto: Array[0]

VAL

Object
-IuRgBJ5eQ5wRIkaoHA9: Object
-IuRuk-qMruhFm2YoU8T: Object
-IuRuls6gDKy__51ttFu: Object
-IuRumTqD0s8fmEcz7hO: Object
-IuRuy5D5vEtTGQRpYsQ: Object
-IuRw_kBP1ul6aDF-HjO: Object
-IuRwgfDa8Y2eMJmeT2y: Object
-IuRzWLcy0lW-pC_6tgs: Object
-IuRzZiJytNHytMxxvWd: Object
-IuRzb92sNn2ua8Tepyy: Object
-IuRzcSEa3A5mClHQQoc: Object
-IuTYcDAv9R3Kiwh5Rl2: Object
-IuTcwzhyG7htE6PSvAv: Object
proto: Object

[pmoelgaard]

I guess there is no update as to why there is a type misalignment... too bad, because Im experiencing it on my other repositories as well... and it makes it impossible to use splice and push on the collection, so I can't use implicit synchronization

[katowulf]

@pmoelgaard I'd highly suggest posting this as its own issue instead of nesting it in the comment thread of another issue.

[jaredwilli]

I believe I've also run into this same error too, which if my memory serves me correct, the thing I did to fix it from happening was change all instances which angularFire is doing == to === and also != to !==.

I've been curious to know what if any, reasons there may be for using double = and != in the code for things, rather than check for the absolute equality or inequality. I have a feeling that the type coercion issues are because of this. It shouldn't be checking for a falsey or truthy value, not all the time anyways.

If you do try this, I'd love to know if it worked, or if there are any specific reasons for how it is done in angularFire, i'd also love to know that too.

[anantn]

@jaredwilli You're right, we should switch over to === and !== as appropriate. Would it be possible for you to post your changes to angularFire somewhere? Perhaps a fork on Github?