What's the best practice for accessing the "user" object from a directive
with an isolated scope? In the previous version of the angularfire seed,
the auth.user object was simply stored in the rootscope - was the logic
rewritten to make authentication more secure? If so, I don't want to undo
those benefits by needlessly passing around the "user" object. Can someone
help by elaborating here? Thanks!

--
You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
To post to this group, send email to firebase-angular@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Michael Wulf at Aug 12, 2014 at 4:16 am
    Nothing has changed regarding $firebaseSimpleLogin in the latest release.
    We'll be reviewing it and probably making some API updates before the 1.0
    milestone, but for now, it remains as-is.

    Cheers,

    On Mon, Aug 11, 2014 at 8:34 PM, Kathy wrote:

    What's the best practice for accessing the "user" object from a directive
    with an isolated scope? In the previous version of the angularfire seed,
    the auth.user object was simply stored in the rootscope - was the logic
    rewritten to make authentication more secure? If so, I don't want to undo
    those benefits by needlessly passing around the "user" object. Can someone
    help by elaborating here? Thanks!

    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/CAFHX4%3DpkpTg4JMEjTMzM%3DRHyNVgsb10f47Ewt09rpC4HW0Hg%3Dg%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kathy at Aug 13, 2014 at 3:53 am
    Whoops - I deleted the original question by accident. Thanks for the
    response. I suppose I was referring more to the structure of the updated
    angularfire-seed rather than $firebaseSimpleLogin. It looks like the
    "simpleLogin" factory was rewritten, and authentication in app.js no longer
    stores the login object in $rootScope.auth. What's the rationale behind
    this change? Why is it better not to store the login object in $rootScope?
    If not storing in $rootScope, what's the best practice for persisting a uid
    that all directives can access? Thanks!
    On Tuesday, August 12, 2014 12:16:21 AM UTC-4, Michael Kato Wulf wrote:

    Nothing has changed regarding $firebaseSimpleLogin in the latest release.
    We'll be reviewing it and probably making some API updates before the 1.0
    milestone, but for now, it remains as-is.

    Cheers,


    On Mon, Aug 11, 2014 at 8:34 PM, Kathy <kq...@squaresixteen.com
    <javascript:>> wrote:
    What's the best practice for accessing the "user" object from a directive
    with an isolated scope? In the previous version of the angularfire seed,
    the auth.user object was simply stored in the rootscope - was the logic
    rewritten to make authentication more secure? If so, I don't want to undo
    those benefits by needlessly passing around the "user" object. Can someone
    help by elaborating here? Thanks!

    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angul...@googlegroups.com <javascript:>.
    To post to this group, send email to firebase...@googlegroups.com
    <javascript:>.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/75fdfa41-def4-4024-8ffb-08004c4425d9%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kathy at Aug 13, 2014 at 4:36 am
    To elaborate, my current solution is just to add a "returnUser: function() {return
    auth.user;}" function to the "simpleLogin" factory and it works fine. I am
    probably overthinking the security implications :).
    On Tuesday, August 12, 2014 11:53:18 PM UTC-4, Kathy wrote:

    Whoops - I deleted the original question by accident. Thanks for the
    response. I suppose I was referring more to the structure of the updated
    angularfire-seed rather than $firebaseSimpleLogin. It looks like the
    "simpleLogin" factory was rewritten, and authentication in app.js no longer
    stores the login object in $rootScope.auth. What's the rationale behind
    this change? Why is it better not to store the login object in $rootScope?
    If not storing in $rootScope, what's the best practice for persisting a uid
    that all directives can access? Thanks!
    On Tuesday, August 12, 2014 12:16:21 AM UTC-4, Michael Kato Wulf wrote:

    Nothing has changed regarding $firebaseSimpleLogin in the latest release.
    We'll be reviewing it and probably making some API updates before the 1.0
    milestone, but for now, it remains as-is.

    Cheers,

    On Mon, Aug 11, 2014 at 8:34 PM, Kathy wrote:

    What's the best practice for accessing the "user" object from a
    directive with an isolated scope? In the previous version of the
    angularfire seed, the auth.user object was simply stored in the rootscope -
    was the logic rewritten to make authentication more secure? If so, I don't
    want to undo those benefits by needlessly passing around the "user" object.
    Can someone help by elaborating here? Thanks!

    --
    You received this message because you are subscribed to the Google
    Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to firebase-angul...@googlegroups.com.
    To post to this group, send email to firebase...@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/38912be9-aea7-4a28-82c8-a4a1de9969ae%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael Wulf at Aug 13, 2014 at 5:11 am
    simpleLogin already has a user object on it
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/simpleLogin.js#L29>
    (to
    be used when you're sure the user is already loaded) as well as a getUser
    method (to be used when you aren't sure login will be loaded yet; this one
    is good for use in your resolve methods). But again, the best method is
    just to use resolve in the router and pass the user object into the
    controller as a dependency in most cases.

    On Tue, Aug 12, 2014 at 9:36 PM, Kathy wrote:

    To elaborate, my current solution is just to add a "returnUser: function()
    {return auth.user;}" function to the "simpleLogin" factory and it works
    fine. I am probably overthinking the security implications :).

    On Tuesday, August 12, 2014 11:53:18 PM UTC-4, Kathy wrote:

    Whoops - I deleted the original question by accident. Thanks for the
    response. I suppose I was referring more to the structure of the updated
    angularfire-seed rather than $firebaseSimpleLogin. It looks like the
    "simpleLogin" factory was rewritten, and authentication in app.js no longer
    stores the login object in $rootScope.auth. What's the rationale behind
    this change? Why is it better not to store the login object in $rootScope?
    If not storing in $rootScope, what's the best practice for persisting a uid
    that all directives can access? Thanks!
    On Tuesday, August 12, 2014 12:16:21 AM UTC-4, Michael Kato Wulf wrote:

    Nothing has changed regarding $firebaseSimpleLogin in the latest
    release. We'll be reviewing it and probably making some API updates before
    the 1.0 milestone, but for now, it remains as-is.

    Cheers,

    On Mon, Aug 11, 2014 at 8:34 PM, Kathy wrote:

    What's the best practice for accessing the "user" object from a
    directive with an isolated scope? In the previous version of the
    angularfire seed, the auth.user object was simply stored in the rootscope -
    was the logic rewritten to make authentication more secure? If so, I don't
    want to undo those benefits by needlessly passing around the "user" object.
    Can someone help by elaborating here? Thanks!

    --
    You received this message because you are subscribed to the Google
    Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to firebase-angul...@googlegroups.com.
    To post to this group, send email to firebase...@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/
    msgid/firebase-angular/b8dd36a4-a234-44c2-8725-
    36f718d712b0%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/38912be9-aea7-4a28-82c8-a4a1de9969ae%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/38912be9-aea7-4a28-82c8-a4a1de9969ae%40googlegroups.com?utm_medium=email&utm_source=footer>
    .

    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/CAFHX4%3DoMAJFSSi1zzLbFbXM8%2BHzEG5p9rY8RLx4CTMyg44ZTog%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kathy at Aug 13, 2014 at 2:56 pm
    That makes sense - thanks for the elaboration!
    On Wednesday, August 13, 2014 1:11:45 AM UTC-4, Michael Kato Wulf wrote:

    simpleLogin already has a user object on it
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/simpleLogin.js#L29> (to
    be used when you're sure the user is already loaded) as well as a getUser
    method (to be used when you aren't sure login will be loaded yet; this one
    is good for use in your resolve methods). But again, the best method is
    just to use resolve in the router and pass the user object into the
    controller as a dependency in most cases.


    On Tue, Aug 12, 2014 at 9:36 PM, Kathy <kq...@squaresixteen.com
    <javascript:>> wrote:
    To elaborate, my current solution is just to add a "returnUser:
    function() {return auth.user;}" function to the "simpleLogin" factory
    and it works fine. I am probably overthinking the security implications :).

    On Tuesday, August 12, 2014 11:53:18 PM UTC-4, Kathy wrote:

    Whoops - I deleted the original question by accident. Thanks for the
    response. I suppose I was referring more to the structure of the updated
    angularfire-seed rather than $firebaseSimpleLogin. It looks like the
    "simpleLogin" factory was rewritten, and authentication in app.js no longer
    stores the login object in $rootScope.auth. What's the rationale behind
    this change? Why is it better not to store the login object in $rootScope?
    If not storing in $rootScope, what's the best practice for persisting a uid
    that all directives can access? Thanks!
    On Tuesday, August 12, 2014 12:16:21 AM UTC-4, Michael Kato Wulf wrote:

    Nothing has changed regarding $firebaseSimpleLogin in the latest
    release. We'll be reviewing it and probably making some API updates before
    the 1.0 milestone, but for now, it remains as-is.

    Cheers,

    On Mon, Aug 11, 2014 at 8:34 PM, Kathy wrote:

    What's the best practice for accessing the "user" object from a
    directive with an isolated scope? In the previous version of the
    angularfire seed, the auth.user object was simply stored in the rootscope -
    was the logic rewritten to make authentication more secure? If so, I don't
    want to undo those benefits by needlessly passing around the "user" object.
    Can someone help by elaborating here? Thanks!

    --
    You received this message because you are subscribed to the Google
    Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to firebase-angul...@googlegroups.com.
    To post to this group, send email to firebase...@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/
    msgid/firebase-angular/b8dd36a4-a234-44c2-8725-
    36f718d712b0%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angul...@googlegroups.com <javascript:>.
    To post to this group, send email to firebase...@googlegroups.com
    <javascript:>.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/38912be9-aea7-4a28-82c8-a4a1de9969ae%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/38912be9-aea7-4a28-82c8-a4a1de9969ae%40googlegroups.com?utm_medium=email&utm_source=footer>
    .

    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/c43e5bda-2b03-444f-a0e4-1939e9608b25%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael Wulf at Aug 13, 2014 at 5:09 am
    Kathy,

    You're free to put it into $rootScope if that's easiest. In general, you
    can just inject the simpleLogin dependency and get the id as needed, so it
    doesn't seem necessary to throw around globals. But this is simply a
    pragmatic programming principle and you're free to disagree.

    If you're getting the user in your directives just to see if they are
    logged in, you probably don't need to. You should probably just
    utilize a resolve
    in the router
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/routes.js#L14>
    to make sure they are logged in ahead of time--keep things DRY. If you're
    doing something specific to authentication, check out the ngShowAuth and
    ngHideAuth
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/directives.js>
    directives for examples of how to inject simpleLogin and utilize it.

    Cheers,

    On Mon, Aug 11, 2014 at 9:16 PM, Michael Wulf wrote:

    Nothing has changed regarding $firebaseSimpleLogin in the latest release.
    We'll be reviewing it and probably making some API updates before the 1.0
    milestone, but for now, it remains as-is.

    Cheers,

    On Mon, Aug 11, 2014 at 8:34 PM, Kathy wrote:

    What's the best practice for accessing the "user" object from a directive
    with an isolated scope? In the previous version of the angularfire seed,
    the auth.user object was simply stored in the rootscope - was the logic
    rewritten to make authentication more secure? If so, I don't want to undo
    those benefits by needlessly passing around the "user" object. Can someone
    help by elaborating here? Thanks!

    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/b8dd36a4-a234-44c2-8725-36f718d712b0%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/CAFHX4%3Dqf3va1b5QP1u%3Dc%3DqHu9TheMCBzDeKRjMCVN7875oTt7w%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupfirebase-angular @
postedAug 12, '14 at 3:51a
activeAug 13, '14 at 2:56p
posts7
users2

2 users in discussion

Kathy: 4 posts Michael Wulf: 3 posts

People

Translate

site design / logo © 2021 Grokbase