I got authentication working with firebase, angularFire, and firebase
simple login.

I'd like to be able to access and write to the user's Gists.

Is there a way to make Github API calls to get and write the Gists with
firebase's tools?

Thanks,

Bob

--
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/e4ca626c-9308-432a-ba74-5c820db3298f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Jacob Wenger at Aug 8, 2014 at 8:58 pm
    Hey Bob,

    Great question! GitHub has pretty good documentation on their API
    <https://developer.github.com/v3/> so make sure you give that a read. For
    things like listing a user's gists
    <https://developer.github.com/v3/gists/#list-gists>, all you need to do is
    make a request to this URL:

    https://api.github.com/users/:username/gists

    Just replace :username with the username returned in thirdPartyUserData
    from Simple Login. For example, here are all of Kato's gists
    <https://api.github.com/users/katowulf/gists> (I would show mine, but I
    have none to show). Note that this only returns their *public* gists. And
    you only get read access, so you cannot create new gists for their account.

    If you want to get their private gists and/or get write privilege, you need
    to request the gist scope when you call login with Simple Login because by
    default we only request their basic public profile information:

    auth.login("github", {
       scope: "gist"
    })

    You also need to tack on an access token to the query string of your
    request. Thankfully, Simple Login sends you this as accessToken in the user
    payload after logging the user in. Your request would then look like this
    (note the casing difference between our accessToken and GitHub's
    access_token):

    https://api.github.com/users/:username/gists?access_token=<access_token_from_Simple_Login>

    There are many different ways you can get this data via this URL. You can
    of course visit it in a browser, but you can also do a curl command from
    the command line:

    curl
    https://api.github.com/users/:username/gists?access_token=<access_token_from_Simple_Login>

    I bet you want to do it from JavaScript though. If you are using jQuery, it
    would look like this:

    $.getJSON("https://api.github.com/users/:username/gists", {
       access_token: user.accessToken
    }).then(function(gists) {
       console.log("Gists:", gists);
    }).catch(function(error) {
       console.log("Error making GitHub request:", error);
    });

    If you want to use plain old JavaScript and no framework, you'll need to
    use XMLHttpRequest. This Stack Overflow example
    <http://stackoverflow.com/questions/10341135/example-of-using-github-api-from-javascript>
    explains how to do that nicely.

    Thanks for your question. I'm hoping to get this kind of information into
    our documentation soon.

    Jacob
    On Thursday, August 7, 2014 9:53:37 PM UTC-7, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/647c3691-2693-4c7d-9e48-d1adeec84b45%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Piotr Kaminski at Aug 8, 2014 at 10:24 pm
    On top of what Jacob said, you might want to use a library that wraps the
    calls to the GitHub API to take advantage of some of its features (e.g.,
    ETags to avoid transmitting duplicate data). Here's what a call would look
    like using Hubkit <https://github.com/pkaminski/hubkit>:

    new Hubkit({token: user.accessToken}).request('GET /users/:username/gists',
    user).then(/* as above */);

    It's a very small library but it gets some of the annoying stuff out of the
    way.

         -- P.


    On Fri, Aug 8, 2014 at 1:58 PM, Jacob Wenger wrote:

    Hey Bob,

    Great question! GitHub has pretty good documentation on their API
    <https://developer.github.com/v3/> so make sure you give that a read. For
    things like listing a user's gists
    <https://developer.github.com/v3/gists/#list-gists>, all you need to do
    is make a request to this URL:

    https://api.github.com/users/:username/gists

    Just replace :username with the username returned in thirdPartyUserData
    from Simple Login. For example, here are all of Kato's gists
    <https://api.github.com/users/katowulf/gists> (I would show mine, but I
    have none to show). Note that this only returns their *public* gists. And
    you only get read access, so you cannot create new gists for their account.

    If you want to get their private gists and/or get write privilege, you
    need to request the gist scope when you call login with Simple Login
    because by default we only request their basic public profile information:

    auth.login("github", {
    scope: "gist"
    })

    You also need to tack on an access token to the query string of your
    request. Thankfully, Simple Login sends you this as accessToken in the
    user payload after logging the user in. Your request would then look like
    this (note the casing difference between our accessToken and GitHub's
    access_token):

    https://api.github.com/users/:username/gists?access_token=
    <access_token_from_Simple_Login>

    There are many different ways you can get this data via this URL. You can
    of course visit it in a browser, but you can also do a curl command from
    the command line:

    curl https://api.github.com/users/:username/gists?access_token=
    <access_token_from_Simple_Login>

    I bet you want to do it from JavaScript though. If you are using jQuery,
    it would look like this:

    $.getJSON("https://api.github.com/users/:username/gists", {
    access_token: user.accessToken
    }).then(function(gists) {
    console.log("Gists:", gists);
    }).catch(function(error) {
    console.log("Error making GitHub request:", error);
    });

    If you want to use plain old JavaScript and no framework, you'll need to
    use XMLHttpRequest. This Stack Overflow example
    <http://stackoverflow.com/questions/10341135/example-of-using-github-api-from-javascript>
    explains how to do that nicely.

    Thanks for your question. I'm hoping to get this kind of information into
    our documentation soon.

    Jacob

    On Thursday, August 7, 2014 9:53:37 PM UTC-7, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/647c3691-2693-4c7d-9e48-d1adeec84b45%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/647c3691-2693-4c7d-9e48-d1adeec84b45%40googlegroups.com?utm_medium=email&utm_source=footer>
    .

    For more options, visit https://groups.google.com/d/optout.


    --
       Piotr Kaminski <piotr@ideanest.com>
       "That bun is dirty. Don't eat that bun."

    --
    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/CANF_M5z%2BOJBPN4EFcB79Zo6kPhas7wJ%3Dz1mbfQ%3DuPFmh3yfJDA%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Monteverde at Aug 9, 2014 at 8:02 pm
    Well, I've been reading through the angularFire and Simple Login
    documentation.

    I made a simpleLogin service, basically returning what used to be my auth
    object. And I made a currentUser resolve that simply does
    simpleLogin.$getCurrentUser()

    I'm using angular-ui router, I like some of the additional features it
    provides. I'm wondering if my basic page/app structure makes sense.
      Here's what I'm starting with:

    <body ng-app="mChartsWebApp">

       <div class="container" ng-controller="MainCtrl">
         <div ng-include="'/views/header.html'"></div>

         <ui-view></ui-view>

         <div ng-include="'/views/footer.html'"></div>
       </div>


    </body>


    The reason I have a MainCtrl wrapping everything is because in the header I
    would like to have a login button if the user is not logged in, or a user
    dropdown menu with a few links (ie. user profile) and a logout button.

    While I have a currentUser resolve, because the MainCtrl is not linked to a
    state, I can't use a resolve, so instead I'm calling
    simpleLogin.$getCurrentUser() and setting the result to $scope.user.

    I suppose this isn't as elegant as it could be, if you are logged in,
    you'll see the Log in button flash until get $getCurrentUser promise comes
    back.


    So now, I'm starting to wonder if this is really the best way to set things
    up. If I do things this way, the MainCtrl will have gotten the user, in
    which case, I suppose I would never need the currentUser resolve since all
    the other controllers will be a child of the MainCtrl and I can just access
    it. In fact, if I do that, I could actually not even have the simpleLogin
    service... I could just set $scope.auth in the main controller to this.


    Unless I'm mistaken, I should be able to do what I described above. But
    this is JavaScript... and just because you can do something, or something
    works, doesn't mean it's "right".

    I'm guessing my basic layout isn't too far from how other people set up
    there apps. That is, having a header that's persistent across all pages
    that requires some controller to access values on $scope in the HTML.

    It would seem weird to me to have a parent state that ALL states are a
    descendant, though that would then allow me to use a resolve on it, and
    prevent a flicker of the login button (though, I don't think I really care
    about the flicker. But I'm also asking this because I've set up a similar
    thing for my job, and a flicker like that may annoy the boss, he seems to
    care a lot about small visual "bugs" even if they are very minor).

    Another idea, since I'm using ui-router would be to have a named ui-view
    for the header. This way I could have a controller with a resolve, even
    though it would always be the same controller across the entire app.


    Also, I am wondering, if I were to have a parent controller across the
    whole app like I do now, and in it I create a new Firebase reference,
    should I also put this object on the $scope so all the other controllers
    will have access to it, and not have to create their own Firebase reference.


    Anyway, I'd imagine this being a extremely common setup (not the way I
    currently have it, just my goals of having a header that's site wide that
    has the login/logout functionality, as well as having a user menu if logged
    in). I'd like to do things "right"... which I mean, I'd like to do things
    in the most commonly acceptable manor.

    Any advice/recommendations would be amazing. I've been using Angular at
    work for some time, and have played around with simple sites on my own...
    but I'm still trying to get a feel for the most common/acceptable way to
    organize things (getting decent and separating my code between controllers,
    services, directive, and resolves... but its not always natural to me... or
    at least sometimes my first thought isn't how I end up deciding to arrange
    things once I finish and refactor a feature).


    Thanks again for the help. I'm trying my best to read the tutorials and
    any info I can find. I don't wanna waste people's time explaining things
    that are word for word in documentation. But at the same time, the more
    advice I can get from people more comfortable/experienced with Angular and
    Firebase, the better off I'll be.

    Bob

    On Friday, August 8, 2014 4:58:10 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    Great question! GitHub has pretty good documentation on their API
    <https://www.google.com/url?q=https%3A%2F%2Fdeveloper.github.com%2Fv3%2F&sa=D&sntz=1&usg=AFQjCNEJnhpqHSzWjdowCka3Lb1Uma0MjQ> so
    make sure you give that a read. For things like listing a user's gists
    <https://developer.github.com/v3/gists/#list-gists>, all you need to do
    is make a request to this URL:

    https://api.github.com/users/:username/gists

    Just replace :username with the username returned in thirdPartyUserData
    from Simple Login. For example, here are all of Kato's gists
    <https://api.github.com/users/katowulf/gists> (I would show mine, but I
    have none to show). Note that this only returns their *public* gists. And
    you only get read access, so you cannot create new gists for their account.

    If you want to get their private gists and/or get write privilege, you
    need to request the gist scope when you call login with Simple Login
    because by default we only request their basic public profile information:

    auth.login("github", {
    scope: "gist"
    })

    You also need to tack on an access token to the query string of your
    request. Thankfully, Simple Login sends you this as accessToken in the
    user payload after logging the user in. Your request would then look like
    this (note the casing difference between our accessToken and GitHub's
    access_token):

    https://api.github.com/users/:username/gists?access_token=
    <access_token_from_Simple_Login>

    There are many different ways you can get this data via this URL. You can
    of course visit it in a browser, but you can also do a curl command from
    the command line:

    curl https://api.github.com/users/:username/gists?access_token=
    <access_token_from_Simple_Login>

    I bet you want to do it from JavaScript though. If you are using jQuery,
    it would look like this:

    $.getJSON("https://api.github.com/users/:username/gists", {
    access_token: user.accessToken
    }).then(function(gists) {
    console.log("Gists:", gists);
    }).catch(function(error) {
    console.log("Error making GitHub request:", error);
    });

    If you want to use plain old JavaScript and no framework, you'll need to
    use XMLHttpRequest. This Stack Overflow example
    <http://stackoverflow.com/questions/10341135/example-of-using-github-api-from-javascript>
    explains how to do that nicely.

    Thanks for your question. I'm hoping to get this kind of information into
    our documentation soon.

    Jacob
    On Thursday, August 7, 2014 9:53:37 PM UTC-7, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/50951dca-758b-4ee4-9541-13cd3b16f6ff%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Monteverde at Aug 9, 2014 at 8:02 pm
    Thank you Jacob, wonderful info... really appreciate you taking the time to
    get that specific (I didn't know about the scopes object on simple login).

    And thank's Piotr, I'll definitely check it out.


    While this is OT from this thread, I might as well bring up my concerns...

    While Firebase is an amazing service, and the angularFire and simple login
    add-ons are fantastic and really simple (Seriously, firebase basically
    takes care of all of the "boring and tedious" code I find no enjoyment in
    writing, letting me stick to what I enjoy doing).... I'm kinda concerned
    with security. I suppose it really depends on what the scope of my project
    is, this one I may have less concern with (at least on the Github side, if
    you wanna hack the code, you're only gonna be hacking your Gists, not like
    you can write to others). But in general, when it comes to the data I'd
    have in firebase, the stuff I really love about it (basically it really
    being almost automatic in creating collections, etc), seems like it would
    be insanely open to someone "hacking" the system and really screwing up my
    firebase stored data. This is really the whole front-end vs back-end
    separation concerns, considering firebase pretty much makes my app all
    front end. In a normal app, say one that's using node and mongo on the
    backend instead of firebase, it's pretty straight forward how to protect my
    app and prevent users from doing anything I don't want them to. What can I
    do with firebase to get the same kind of security I would have if I were to
    have my own backend API/AUTH server protecting my app and data, only
    allowing what I want to be allowed to do even if a user attempts to "hack"
    things.

    (BTW, I'm using quotes around "hack[ing]" because I consider hacking to
    really be a little more involved then messing around with a sites front end
    code. Basically, if I can do it, I don't really consider it real hacking,
    lol)


    Thanks,

    Bob

    On Friday, August 8, 2014 4:58:10 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    Great question! GitHub has pretty good documentation on their API
    <https://developer.github.com/v3/> so make sure you give that a read. For
    things like listing a user's gists
    <https://developer.github.com/v3/gists/#list-gists>, all you need to do
    is make a request to this URL:

    https://api.github.com/users/:username/gists

    Just replace :username with the username returned in thirdPartyUserData
    from Simple Login. For example, here are all of Kato's gists
    <https://api.github.com/users/katowulf/gists> (I would show mine, but I
    have none to show). Note that this only returns their *public* gists. And
    you only get read access, so you cannot create new gists for their account.

    If you want to get their private gists and/or get write privilege, you
    need to request the gist scope when you call login with Simple Login
    because by default we only request their basic public profile information:

    auth.login("github", {
    scope: "gist"
    })

    You also need to tack on an access token to the query string of your
    request. Thankfully, Simple Login sends you this as accessToken in the
    user payload after logging the user in. Your request would then look like
    this (note the casing difference between our accessToken and GitHub's
    access_token):

    https://api.github.com/users/:username/gists?access_token=
    <access_token_from_Simple_Login>

    There are many different ways you can get this data via this URL. You can
    of course visit it in a browser, but you can also do a curl command from
    the command line:

    curl https://api.github.com/users/:username/gists?access_token=
    <access_token_from_Simple_Login>

    I bet you want to do it from JavaScript though. If you are using jQuery,
    it would look like this:

    $.getJSON("https://api.github.com/users/:username/gists", {
    access_token: user.accessToken
    }).then(function(gists) {
    console.log("Gists:", gists);
    }).catch(function(error) {
    console.log("Error making GitHub request:", error);
    });

    If you want to use plain old JavaScript and no framework, you'll need to
    use XMLHttpRequest. This Stack Overflow example
    <http://stackoverflow.com/questions/10341135/example-of-using-github-api-from-javascript>
    explains how to do that nicely.

    Thanks for your question. I'm hoping to get this kind of information into
    our documentation soon.

    Jacob
    On Thursday, August 7, 2014 9:53:37 PM UTC-7, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/1ca2c08a-bf7e-4d85-8c86-ce556a70db65%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Monteverde at Aug 9, 2014 at 8:02 pm
    With regards to my last post.. what do you guys think of this
    structure: http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/fd47dad9-2a64-4f3a-8a18-946ac3fdf5da%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jacob Wenger at Aug 9, 2014 at 9:42 pm
    Hey Bob,

    You are asking great questions and I am happy to help. But in the future,
    please create new threads in this Google Group for different, off-topic
    questions. That way when someone in the future searches Google for say
    "GitHub and Simple Login", they can easily find the answer and not have it
    mixed with these other questions. Thanks!

    Now, on to your questions. First I'll tackle security. Security is a huge
    deal for us here at Firebase and we think we have a come up with a pretty
    awesome solution, called Security Rules
    <https://www.firebase.com/docs/security/>. Security Rules allows you to
    define the schema of your data and who has read and write access to every
    piece of data. It is just a JSON object stored in your Firebase and we
    ensure the Security Rules on our servers, meaning they can't be bypassed on
    the client-side. Security Rules get really powerful when you combine it
    with Simple Login to create the auth variable
    <https://www.firebase.com/docs/security/guide.html#section-variable>. I
    could go on and on about Security Rules, but our documentation has a ton of
    information already about this <https://www.firebase.com/docs/security/>.
    If you read through the quickstart, guide, and API and still have concerns,
    please let me know and I can help you settle them. I want to assure you
    though that any type of security you could set on your data in Mongo can
    also be set on your data in Firebase. The security mechanism certainly
    looks a lot different, but it just as powerful - if not more so. One last
    link for you: we have a project called the Blaze compiler which is
    currently in beta which makes it even easier to write and test security
    rules. Here is a link to it on GitHub
    <https://github.com/firebase/blaze_compiler>.

    Now, to the structure of your AngularFire app. You asked a lot of questions
    and I'm unfortunately not sure I can answer them all in a reasonable amount
    of time. Let me point you to our documentation on this exact topic though.
    In our new AngularFire guide for our 0.8.0 release, we have a section
    called "Authentication
    <https://www.firebase.com/docs/web/libraries/angular/guide.html#section-angular-authentication>."
    In that section is a sub-section called "Using Simple Login With Routers."
    I have a feeling that section will explain how to combine AngularFire with
    Simple Login to get the effect you want (i.e. "clean" code and no flash of
    unauthenticated data). Essentially, you need to be using the resolve attribute
    in your route provider to get rid of the flash you are seeing. If you still
    have some questions, please don't be afraid to start a new thread and ask
    away. Please try to be specific in your questions so that we can give you
    direct answers. Sharing Plunkers are super helpful and much appreciated, so
    thank you for that!

    Good luck!
    Jacob
    On Saturday, August 9, 2014 7:39:14 AM UTC-7, Bob Monteverde wrote:

    With regards to my last post.. what do you guys think of this structure:
    http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/77f94418-ad67-448d-965b-23ca9b8ebe44%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Monteverde at Aug 10, 2014 at 12:51 am
    Hey Jacob,

    Thanks again for the info, and great sum up of how security works, should
    be easy enough to go from there. I did spend time over the last night and
    day and pretty much covered everything you mentioned.

    My main question from the previous posts, which is not exactly answered in
    the docs you brought up, is more how you would go about setting up the base
    structure of the HTML, and general controller setup in Angular with
    ui-router. My original code in my second post was what I originally had.
      I have now switched over to similar to the plunkr. Basically in my index
    I have 3 named views "header", "main", and "footer". Instead of having a
    "MainCtrl" on a wrapping container to those 3, I'm using named views, and
    having a parent "root" state that every single state is a descendant of.
      Now I can set a "HeaderCtrl" that has the "currentUser" resolve, and also
    has the $scope.login and $scope.logout functions. But since the header is
    on it's own, if I need to user object in other controller, I could either
    resolve the "currentUser" in them, or if I don't need it before loading
    state, could inject the "simpleUser" service and call "$getCurrentUser"
    inside the controller. The plunker above pretty much has the structure I
    just described, just with the simpleUser service and currentUser resolve as
    described in the angularFire quick start docs.

    So back to what my question actually is. I suppose the previous set up I
    had and this set up both could do the job. But I figure it's a really
    standard setup, so if you have enough experience with Angular, I really
    just wanna know if the previous way or the way I just described (with
    minimal example in plunkr) is the more common way of setting up an app.
      Also if anything sticks out in either that sounds like I'm doing it wrong,
    or could do it better, would be great to know.

    I'll try to quickly sum up the 2 different strategies I have tried that I
    just described again above... using pseudo markup and code

    A) <container ng-controller="MainCtrl"> <header/> <main ui-view/>
    <footer/> </container>

    The MainCtrl having the Login/Logout and simpleLogin.$getCurrentUser() call
    within the controller (No resolve since the MainCtrl is not linked to a
    state here). All other top level states would be set inside the "<main/>"
    . Because all controllers are within the MainCtrl, they can access the
    user object from the MainCtrl's $scope.user.


    B) <ui-view="header" /> <ui-view="main" /> <ui-view="footer" />

    All states are descendant of "root". "root" sets the header and footer
    templates (that will be used across the app) and the header has a
    "HeaderCtrl" with a "currentUser" resolve. All descendant states are
    within the "main" ui-view. If they need the user object, they will either
    need to resolve the "currentUser" OR get it themselves view the
    "simpleLogin" service.


    Again, this is just a repeat of what I was trying to ask before, and
    attempting to summarize the 2 setups I have tried, wondering what setup is
    the "better" (well, say more common) structure. Since finding the plunkr
    that pretty much described setup "B", I'm leaning towards that way, but
    would love any input and/or changes that may be recommended to either setup
    A or B.


    And the only other real question I have, which might be only relevant to
    setup A, is... Doe's it make sense to only have a single 'var ref = new
    Firebase(...)' and maybe set that ref onto the MainCtrl's $scope so
    descendant controllers don;t need to keep making the Firebase ref?... or
    should there be a simple 1 line service for getting this ref? (that doesn't
    really sound practical, but I don't know enough to say yes or no).... OR do
    I just setup "var ref = new Firebase(...)" in every controller that I need
    the ref to access Firebase data.

      In attempt to answer my own question, the docs say that the reference to
    the new Firebase doesn;t cost much since it doesn;t make a call till I
    actually get the data, so I'm thinking I could just have "var ref = new
    Firebase(..)" at the top of each controller that I would need. But then
    again, maybe it makes sense just to have a service to get that for me.


    Thank again, hopefully I described the different options I am trying good
    enough that you can give me a good enough recommendation. I suppose one of
    the best things I could do is look at as many angular projects I can find
    to see how they do it. The header with the login function and/or user menu
    has to be a beyond common setup... which i why I'm asking questions like
    these. Trying to keep my code organized as best I can, and the more
    similar it is to how others do it, the easier it'll be to find good
    examples to base my code off of. ]


    Thanks again,and sorry for the long post, was trying my best to summarize
    the setups while still cramming enough info in there tht hopefully you
      understand the 2 different setups I have tried so far.

    Bob

    On Saturday, August 9, 2014 5:42:48 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    You are asking great questions and I am happy to help. But in the future,
    please create new threads in this Google Group for different, off-topic
    questions. That way when someone in the future searches Google for say
    "GitHub and Simple Login", they can easily find the answer and not have it
    mixed with these other questions. Thanks!

    Now, on to your questions. First I'll tackle security. Security is a huge
    deal for us here at Firebase and we think we have a come up with a pretty
    awesome solution, called Security Rules
    <https://www.firebase.com/docs/security/>. Security Rules allows you to
    define the schema of your data and who has read and write access to every
    piece of data. It is just a JSON object stored in your Firebase and we
    ensure the Security Rules on our servers, meaning they can't be bypassed on
    the client-side. Security Rules get really powerful when you combine it
    with Simple Login to create the auth variable
    <https://www.firebase.com/docs/security/guide.html#section-variable>. I
    could go on and on about Security Rules, but our documentation has a ton
    of information already about this
    <https://www.firebase.com/docs/security/>. If you read through the
    quickstart, guide, and API and still have concerns, please let me know and
    I can help you settle them. I want to assure you though that any type of
    security you could set on your data in Mongo can also be set on your data
    in Firebase. The security mechanism certainly looks a lot different, but it
    just as powerful - if not more so. One last link for you: we have a project
    called the Blaze compiler which is currently in beta which makes it even
    easier to write and test security rules. Here is a link to it on GitHub
    <https://github.com/firebase/blaze_compiler>.

    Now, to the structure of your AngularFire app. You asked a lot of
    questions and I'm unfortunately not sure I can answer them all in a
    reasonable amount of time. Let me point you to our documentation on this
    exact topic though. In our new AngularFire guide for our 0.8.0 release, we
    have a section called "Authentication
    <https://www.firebase.com/docs/web/libraries/angular/guide.html#section-angular-authentication>."
    In that section is a sub-section called "Using Simple Login With Routers."
    I have a feeling that section will explain how to combine AngularFire with
    Simple Login to get the effect you want (i.e. "clean" code and no flash of
    unauthenticated data). Essentially, you need to be using the resolve attribute
    in your route provider to get rid of the flash you are seeing. If you still
    have some questions, please don't be afraid to start a new thread and ask
    away. Please try to be specific in your questions so that we can give you
    direct answers. Sharing Plunkers are super helpful and much appreciated, so
    thank you for that!

    Good luck!
    Jacob
    On Saturday, August 9, 2014 7:39:14 AM UTC-7, Bob Monteverde wrote:

    With regards to my last post.. what do you guys think of this structure:
    http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/a3b90d35-1034-4d8d-b2ff-7c708ef3e64c%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Monteverde at Aug 10, 2014 at 3:00 am
    With regards to the "var ref = new Firebase('...')" ,,, I'm thinking it
    would be pretty ugly to have that in every controller that needs the
    firebase reference. While the service will be very simple, I'm thinking
    maybe that's how I should get the ref into each controller.

    Let me know there's a different technique you guys recommend, or if the
    service s what makes the most sense.

    Bob

    On Saturday, August 9, 2014 8:46:53 PM UTC-4, Bob Monteverde wrote:

    Hey Jacob,

    Thanks again for the info, and great sum up of how security works, should
    be easy enough to go from there. I did spend time over the last night and
    day and pretty much covered everything you mentioned.

    My main question from the previous posts, which is not exactly answered in
    the docs you brought up, is more how you would go about setting up the base
    structure of the HTML, and general controller setup in Angular with
    ui-router. My original code in my second post was what I originally had.
    I have now switched over to similar to the plunkr. Basically in my index
    I have 3 named views "header", "main", and "footer". Instead of having a
    "MainCtrl" on a wrapping container to those 3, I'm using named views, and
    having a parent "root" state that every single state is a descendant of.
    Now I can set a "HeaderCtrl" that has the "currentUser" resolve, and also
    has the $scope.login and $scope.logout functions. But since the header is
    on it's own, if I need to user object in other controller, I could either
    resolve the "currentUser" in them, or if I don't need it before loading
    state, could inject the "simpleUser" service and call "$getCurrentUser"
    inside the controller. The plunker above pretty much has the structure I
    just described, just with the simpleUser service and currentUser resolve as
    described in the angularFire quick start docs.

    So back to what my question actually is. I suppose the previous set up I
    had and this set up both could do the job. But I figure it's a really
    standard setup, so if you have enough experience with Angular, I really
    just wanna know if the previous way or the way I just described (with
    minimal example in plunkr) is the more common way of setting up an app.
    Also if anything sticks out in either that sounds like I'm doing it wrong,
    or could do it better, would be great to know.

    I'll try to quickly sum up the 2 different strategies I have tried that I
    just described again above... using pseudo markup and code

    A) <container ng-controller="MainCtrl"> <header/> <main ui-view/>
    <footer/> </container>

    The MainCtrl having the Login/Logout and simpleLogin.$getCurrentUser()
    call within the controller (No resolve since the MainCtrl is not linked to
    a state here). All other top level states would be set inside the
    "<main/>" . Because all controllers are within the MainCtrl, they can
    access the user object from the MainCtrl's $scope.user.


    B) <ui-view="header" /> <ui-view="main" /> <ui-view="footer" />

    All states are descendant of "root". "root" sets the header and footer
    templates (that will be used across the app) and the header has a
    "HeaderCtrl" with a "currentUser" resolve. All descendant states are
    within the "main" ui-view. If they need the user object, they will either
    need to resolve the "currentUser" OR get it themselves view the
    "simpleLogin" service.


    Again, this is just a repeat of what I was trying to ask before, and
    attempting to summarize the 2 setups I have tried, wondering what setup is
    the "better" (well, say more common) structure. Since finding the plunkr
    that pretty much described setup "B", I'm leaning towards that way, but
    would love any input and/or changes that may be recommended to either setup
    A or B.


    And the only other real question I have, which might be only relevant to
    setup A, is... Doe's it make sense to only have a single 'var ref = new
    Firebase(...)' and maybe set that ref onto the MainCtrl's $scope so
    descendant controllers don;t need to keep making the Firebase ref?... or
    should there be a simple 1 line service for getting this ref? (that doesn't
    really sound practical, but I don't know enough to say yes or no).... OR do
    I just setup "var ref = new Firebase(...)" in every controller that I need
    the ref to access Firebase data.

    In attempt to answer my own question, the docs say that the reference to
    the new Firebase doesn;t cost much since it doesn;t make a call till I
    actually get the data, so I'm thinking I could just have "var ref = new
    Firebase(..)" at the top of each controller that I would need. But then
    again, maybe it makes sense just to have a service to get that for me.


    Thank again, hopefully I described the different options I am trying good
    enough that you can give me a good enough recommendation. I suppose one of
    the best things I could do is look at as many angular projects I can find
    to see how they do it. The header with the login function and/or user menu
    has to be a beyond common setup... which i why I'm asking questions like
    these. Trying to keep my code organized as best I can, and the more
    similar it is to how others do it, the easier it'll be to find good
    examples to base my code off of. ]


    Thanks again,and sorry for the long post, was trying my best to summarize
    the setups while still cramming enough info in there tht hopefully you
    understand the 2 different setups I have tried so far.

    Bob

    On Saturday, August 9, 2014 5:42:48 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    You are asking great questions and I am happy to help. But in the future,
    please create new threads in this Google Group for different, off-topic
    questions. That way when someone in the future searches Google for say
    "GitHub and Simple Login", they can easily find the answer and not have it
    mixed with these other questions. Thanks!

    Now, on to your questions. First I'll tackle security. Security is a huge
    deal for us here at Firebase and we think we have a come up with a pretty
    awesome solution, called Security Rules
    <https://www.firebase.com/docs/security/>. Security Rules allows you to
    define the schema of your data and who has read and write access to every
    piece of data. It is just a JSON object stored in your Firebase and we
    ensure the Security Rules on our servers, meaning they can't be bypassed on
    the client-side. Security Rules get really powerful when you combine it
    with Simple Login to create the auth variable
    <https://www.firebase.com/docs/security/guide.html#section-variable>. I
    could go on and on about Security Rules, but our documentation has a ton
    of information already about this
    <https://www.firebase.com/docs/security/>. If you read through the
    quickstart, guide, and API and still have concerns, please let me know and
    I can help you settle them. I want to assure you though that any type of
    security you could set on your data in Mongo can also be set on your data
    in Firebase. The security mechanism certainly looks a lot different, but it
    just as powerful - if not more so. One last link for you: we have a project
    called the Blaze compiler which is currently in beta which makes it even
    easier to write and test security rules. Here is a link to it on GitHub
    <https://github.com/firebase/blaze_compiler>.

    Now, to the structure of your AngularFire app. You asked a lot of
    questions and I'm unfortunately not sure I can answer them all in a
    reasonable amount of time. Let me point you to our documentation on this
    exact topic though. In our new AngularFire guide for our 0.8.0 release, we
    have a section called "Authentication
    <https://www.firebase.com/docs/web/libraries/angular/guide.html#section-angular-authentication>."
    In that section is a sub-section called "Using Simple Login With Routers."
    I have a feeling that section will explain how to combine AngularFire with
    Simple Login to get the effect you want (i.e. "clean" code and no flash of
    unauthenticated data). Essentially, you need to be using the resolve attribute
    in your route provider to get rid of the flash you are seeing. If you still
    have some questions, please don't be afraid to start a new thread and ask
    away. Please try to be specific in your questions so that we can give you
    direct answers. Sharing Plunkers are super helpful and much appreciated, so
    thank you for that!

    Good luck!
    Jacob
    On Saturday, August 9, 2014 7:39:14 AM UTC-7, Bob Monteverde wrote:

    With regards to my last post.. what do you guys think of this structure:
    http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists with
    firebase's tools?

    Thanks,

    Bob
    --
    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/432d6712-8f7e-4d03-8d70-744df188ea57%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael Wulf at Aug 11, 2014 at 2:28 pm
    Hey Bob,

    In my opinion, a service makes the most sense
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/firebase.utils.js>
    .

    Cheers,

    On Sat, Aug 9, 2014 at 6:25 PM, Bob Monteverde wrote:

    With regards to the "var ref = new Firebase('...')" ,,, I'm thinking it
    would be pretty ugly to have that in every controller that needs the
    firebase reference. While the service will be very simple, I'm thinking
    maybe that's how I should get the ref into each controller.

    Let me know there's a different technique you guys recommend, or if the
    service s what makes the most sense.

    Bob

    On Saturday, August 9, 2014 8:46:53 PM UTC-4, Bob Monteverde wrote:

    Hey Jacob,

    Thanks again for the info, and great sum up of how security works, should
    be easy enough to go from there. I did spend time over the last night and
    day and pretty much covered everything you mentioned.

    My main question from the previous posts, which is not exactly answered
    in the docs you brought up, is more how you would go about setting up the
    base structure of the HTML, and general controller setup in Angular with
    ui-router. My original code in my second post was what I originally had.
    I have now switched over to similar to the plunkr. Basically in my index
    I have 3 named views "header", "main", and "footer". Instead of having a
    "MainCtrl" on a wrapping container to those 3, I'm using named views, and
    having a parent "root" state that every single state is a descendant of.
    Now I can set a "HeaderCtrl" that has the "currentUser" resolve, and also
    has the $scope.login and $scope.logout functions. But since the header is
    on it's own, if I need to user object in other controller, I could either
    resolve the "currentUser" in them, or if I don't need it before loading
    state, could inject the "simpleUser" service and call "$getCurrentUser"
    inside the controller. The plunker above pretty much has the structure I
    just described, just with the simpleUser service and currentUser resolve as
    described in the angularFire quick start docs.

    So back to what my question actually is. I suppose the previous set up I
    had and this set up both could do the job. But I figure it's a really
    standard setup, so if you have enough experience with Angular, I really
    just wanna know if the previous way or the way I just described (with
    minimal example in plunkr) is the more common way of setting up an app.
    Also if anything sticks out in either that sounds like I'm doing it wrong,
    or could do it better, would be great to know.

    I'll try to quickly sum up the 2 different strategies I have tried that I
    just described again above... using pseudo markup and code

    A) <container ng-controller="MainCtrl"> <header/> <main ui-view/>
    <footer/> </container>

    The MainCtrl having the Login/Logout and simpleLogin.$getCurrentUser()
    call within the controller (No resolve since the MainCtrl is not linked to
    a state here). All other top level states would be set inside the
    "<main/>" . Because all controllers are within the MainCtrl, they can
    access the user object from the MainCtrl's $scope.user.


    B) <ui-view="header" /> <ui-view="main" /> <ui-view="footer" />

    All states are descendant of "root". "root" sets the header and footer
    templates (that will be used across the app) and the header has a
    "HeaderCtrl" with a "currentUser" resolve. All descendant states are
    within the "main" ui-view. If they need the user object, they will either
    need to resolve the "currentUser" OR get it themselves view the
    "simpleLogin" service.


    Again, this is just a repeat of what I was trying to ask before, and
    attempting to summarize the 2 setups I have tried, wondering what setup is
    the "better" (well, say more common) structure. Since finding the plunkr
    that pretty much described setup "B", I'm leaning towards that way, but
    would love any input and/or changes that may be recommended to either setup
    A or B.


    And the only other real question I have, which might be only relevant to
    setup A, is... Doe's it make sense to only have a single 'var ref = new
    Firebase(...)' and maybe set that ref onto the MainCtrl's $scope so
    descendant controllers don;t need to keep making the Firebase ref?... or
    should there be a simple 1 line service for getting this ref? (that doesn't
    really sound practical, but I don't know enough to say yes or no).... OR do
    I just setup "var ref = new Firebase(...)" in every controller that I need
    the ref to access Firebase data.

    In attempt to answer my own question, the docs say that the reference to
    the new Firebase doesn;t cost much since it doesn;t make a call till I
    actually get the data, so I'm thinking I could just have "var ref = new
    Firebase(..)" at the top of each controller that I would need. But then
    again, maybe it makes sense just to have a service to get that for me.


    Thank again, hopefully I described the different options I am trying good
    enough that you can give me a good enough recommendation. I suppose one of
    the best things I could do is look at as many angular projects I can find
    to see how they do it. The header with the login function and/or user menu
    has to be a beyond common setup... which i why I'm asking questions like
    these. Trying to keep my code organized as best I can, and the more
    similar it is to how others do it, the easier it'll be to find good
    examples to base my code off of. ]


    Thanks again,and sorry for the long post, was trying my best to summarize
    the setups while still cramming enough info in there tht hopefully you
    understand the 2 different setups I have tried so far.

    Bob

    On Saturday, August 9, 2014 5:42:48 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    You are asking great questions and I am happy to help. But in the
    future, please create new threads in this Google Group for different,
    off-topic questions. That way when someone in the future searches Google
    for say "GitHub and Simple Login", they can easily find the answer and not
    have it mixed with these other questions. Thanks!

    Now, on to your questions. First I'll tackle security. Security is a
    huge deal for us here at Firebase and we think we have a come up with a
    pretty awesome solution, called Security Rules
    <https://www.firebase.com/docs/security/>. Security Rules allows you to
    define the schema of your data and who has read and write access to every
    piece of data. It is just a JSON object stored in your Firebase and we
    ensure the Security Rules on our servers, meaning they can't be bypassed on
    the client-side. Security Rules get really powerful when you combine it
    with Simple Login to create the auth variable
    <https://www.firebase.com/docs/security/guide.html#section-variable>. I
    could go on and on about Security Rules, but our documentation has a
    ton of information already about this
    <https://www.firebase.com/docs/security/>. If you read through the
    quickstart, guide, and API and still have concerns, please let me know and
    I can help you settle them. I want to assure you though that any type of
    security you could set on your data in Mongo can also be set on your data
    in Firebase. The security mechanism certainly looks a lot different, but it
    just as powerful - if not more so. One last link for you: we have a project
    called the Blaze compiler which is currently in beta which makes it even
    easier to write and test security rules. Here is a link to it on GitHub
    <https://github.com/firebase/blaze_compiler>.

    Now, to the structure of your AngularFire app. You asked a lot of
    questions and I'm unfortunately not sure I can answer them all in a
    reasonable amount of time. Let me point you to our documentation on this
    exact topic though. In our new AngularFire guide for our 0.8.0 release, we
    have a section called "Authentication
    <https://www.firebase.com/docs/web/libraries/angular/guide.html#section-angular-authentication>."
    In that section is a sub-section called "Using Simple Login With Routers."
    I have a feeling that section will explain how to combine AngularFire with
    Simple Login to get the effect you want (i.e. "clean" code and no flash of
    unauthenticated data). Essentially, you need to be using the resolve attribute
    in your route provider to get rid of the flash you are seeing. If you still
    have some questions, please don't be afraid to start a new thread and ask
    away. Please try to be specific in your questions so that we can give you
    direct answers. Sharing Plunkers are super helpful and much appreciated, so
    thank you for that!

    Good luck!
    Jacob
    On Saturday, August 9, 2014 7:39:14 AM UTC-7, Bob Monteverde wrote:

    With regards to my last post.. what do you guys think of this
    structure: http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists
    with firebase's tools?

    Thanks,

    Bob
    --
    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/432d6712-8f7e-4d03-8d70-744df188ea57%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/432d6712-8f7e-4d03-8d70-744df188ea57%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%3Do63MHwCL-akpKLmi-HU6gazqWXDtKdNQhTWsqj-MKtuA%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Monteverde at Aug 12, 2014 at 1:05 pm
    I forgot to ask. When loging in with github through firebase, I get an
    access token I need for github API calls. Any chance you know how long
    this token is good for when persisting the login? Or do I just have to try
    an API call and see if it fails?

    Also, what do I do when an API call fails if the user is still logged in?

    Thanks again, I've been busy selecting the parts of the Firbase angular
    seed project to use in my project. I will say, I don;t like some of the
    setup you guys did there. I really don't agree with breaking the app into
    modules like 'myApp.services' 'myApp.routes' 'myApp.filters',,, etc. I
    feel modules, if separate, should enclose a completely funcitonal reusable
    component. So potentially like a set of services, filters, directives...
    etc. I will say, I am debating how to create a config file for things
    like my FB URL. I'm not entirely against the Module you guys did for that,
    but I am looking for other examples to compare that to. Ironically, the
    fact that you guys separated all the different Angular components (as
    described above), which I disagree with, makes me instantly lean against
    even the config... but I'm trying to pretend you guys didn't separate each
    angular component of the app, to look at the config module as viable.

    Bob
    On Monday, August 11, 2014 10:28:51 AM UTC-4, Michael Kato Wulf wrote:

    Hey Bob,

    In my opinion, a service makes the most sense
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/firebase.utils.js>
    .

    Cheers,


    On Sat, Aug 9, 2014 at 6:25 PM, Bob Monteverde <bobmon...@gmail.com
    <javascript:>> wrote:
    With regards to the "var ref = new Firebase('...')" ,,, I'm thinking it
    would be pretty ugly to have that in every controller that needs the
    firebase reference. While the service will be very simple, I'm thinking
    maybe that's how I should get the ref into each controller.

    Let me know there's a different technique you guys recommend, or if the
    service s what makes the most sense.

    Bob

    On Saturday, August 9, 2014 8:46:53 PM UTC-4, Bob Monteverde wrote:

    Hey Jacob,

    Thanks again for the info, and great sum up of how security works,
    should be easy enough to go from there. I did spend time over the last
    night and day and pretty much covered everything you mentioned.

    My main question from the previous posts, which is not exactly answered
    in the docs you brought up, is more how you would go about setting up the
    base structure of the HTML, and general controller setup in Angular with
    ui-router. My original code in my second post was what I originally had.
    I have now switched over to similar to the plunkr. Basically in my index
    I have 3 named views "header", "main", and "footer". Instead of having a
    "MainCtrl" on a wrapping container to those 3, I'm using named views, and
    having a parent "root" state that every single state is a descendant of.
    Now I can set a "HeaderCtrl" that has the "currentUser" resolve, and also
    has the $scope.login and $scope.logout functions. But since the header is
    on it's own, if I need to user object in other controller, I could either
    resolve the "currentUser" in them, or if I don't need it before loading
    state, could inject the "simpleUser" service and call "$getCurrentUser"
    inside the controller. The plunker above pretty much has the structure I
    just described, just with the simpleUser service and currentUser resolve as
    described in the angularFire quick start docs.

    So back to what my question actually is. I suppose the previous set up
    I had and this set up both could do the job. But I figure it's a really
    standard setup, so if you have enough experience with Angular, I really
    just wanna know if the previous way or the way I just described (with
    minimal example in plunkr) is the more common way of setting up an app.
    Also if anything sticks out in either that sounds like I'm doing it wrong,
    or could do it better, would be great to know.

    I'll try to quickly sum up the 2 different strategies I have tried that
    I just described again above... using pseudo markup and code

    A) <container ng-controller="MainCtrl"> <header/> <main ui-view/>
    <footer/> </container>

    The MainCtrl having the Login/Logout and simpleLogin.$getCurrentUser()
    call within the controller (No resolve since the MainCtrl is not linked to
    a state here). All other top level states would be set inside the
    "<main/>" . Because all controllers are within the MainCtrl, they can
    access the user object from the MainCtrl's $scope.user.


    B) <ui-view="header" /> <ui-view="main" /> <ui-view="footer" />

    All states are descendant of "root". "root" sets the header and footer
    templates (that will be used across the app) and the header has a
    "HeaderCtrl" with a "currentUser" resolve. All descendant states are
    within the "main" ui-view. If they need the user object, they will either
    need to resolve the "currentUser" OR get it themselves view the
    "simpleLogin" service.


    Again, this is just a repeat of what I was trying to ask before, and
    attempting to summarize the 2 setups I have tried, wondering what setup is
    the "better" (well, say more common) structure. Since finding the plunkr
    that pretty much described setup "B", I'm leaning towards that way, but
    would love any input and/or changes that may be recommended to either setup
    A or B.


    And the only other real question I have, which might be only relevant to
    setup A, is... Doe's it make sense to only have a single 'var ref = new
    Firebase(...)' and maybe set that ref onto the MainCtrl's $scope so
    descendant controllers don;t need to keep making the Firebase ref?... or
    should there be a simple 1 line service for getting this ref? (that doesn't
    really sound practical, but I don't know enough to say yes or no).... OR do
    I just setup "var ref = new Firebase(...)" in every controller that I need
    the ref to access Firebase data.

    In attempt to answer my own question, the docs say that the reference
    to the new Firebase doesn;t cost much since it doesn;t make a call till I
    actually get the data, so I'm thinking I could just have "var ref = new
    Firebase(..)" at the top of each controller that I would need. But then
    again, maybe it makes sense just to have a service to get that for me.


    Thank again, hopefully I described the different options I am trying
    good enough that you can give me a good enough recommendation. I suppose
    one of the best things I could do is look at as many angular projects I can
    find to see how they do it. The header with the login function and/or user
    menu has to be a beyond common setup... which i why I'm asking questions
    like these. Trying to keep my code organized as best I can, and the more
    similar it is to how others do it, the easier it'll be to find good
    examples to base my code off of. ]


    Thanks again,and sorry for the long post, was trying my best to
    summarize the setups while still cramming enough info in there tht
    hopefully you understand the 2 different setups I have tried so far.

    Bob

    On Saturday, August 9, 2014 5:42:48 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    You are asking great questions and I am happy to help. But in the
    future, please create new threads in this Google Group for different,
    off-topic questions. That way when someone in the future searches Google
    for say "GitHub and Simple Login", they can easily find the answer and not
    have it mixed with these other questions. Thanks!

    Now, on to your questions. First I'll tackle security. Security is a
    huge deal for us here at Firebase and we think we have a come up with a
    pretty awesome solution, called Security Rules
    <https://www.firebase.com/docs/security/>. Security Rules allows you
    to define the schema of your data and who has read and write access to
    every piece of data. It is just a JSON object stored in your Firebase and
    we ensure the Security Rules on our servers, meaning they can't be bypassed
    on the client-side. Security Rules get really powerful when you combine it
    with Simple Login to create the auth variable
    <https://www.firebase.com/docs/security/guide.html#section-variable>.
    I could go on and on about Security Rules, but our documentation has a
    ton of information already about this
    <https://www.firebase.com/docs/security/>. If you read through the
    quickstart, guide, and API and still have concerns, please let me know and
    I can help you settle them. I want to assure you though that any type of
    security you could set on your data in Mongo can also be set on your data
    in Firebase. The security mechanism certainly looks a lot different, but it
    just as powerful - if not more so. One last link for you: we have a project
    called the Blaze compiler which is currently in beta which makes it even
    easier to write and test security rules. Here is a link to it on GitHub
    <https://github.com/firebase/blaze_compiler>.

    Now, to the structure of your AngularFire app. You asked a lot of
    questions and I'm unfortunately not sure I can answer them all in a
    reasonable amount of time. Let me point you to our documentation on this
    exact topic though. In our new AngularFire guide for our 0.8.0 release, we
    have a section called "Authentication
    <https://www.firebase.com/docs/web/libraries/angular/guide.html#section-angular-authentication>."
    In that section is a sub-section called "Using Simple Login With Routers."
    I have a feeling that section will explain how to combine AngularFire with
    Simple Login to get the effect you want (i.e. "clean" code and no flash of
    unauthenticated data). Essentially, you need to be using the resolve attribute
    in your route provider to get rid of the flash you are seeing. If you still
    have some questions, please don't be afraid to start a new thread and ask
    away. Please try to be specific in your questions so that we can give you
    direct answers. Sharing Plunkers are super helpful and much appreciated, so
    thank you for that!

    Good luck!
    Jacob
    On Saturday, August 9, 2014 7:39:14 AM UTC-7, Bob Monteverde wrote:

    With regards to my last post.. what do you guys think of this
    structure: http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists
    with firebase's tools?

    Thanks,

    Bob
    --
    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/432d6712-8f7e-4d03-8d70-744df188ea57%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/432d6712-8f7e-4d03-8d70-744df188ea57%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/ea82df96-b7d0-41db-8a40-241551edda35%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bob Monteverde at Aug 12, 2014 at 1:14 pm
    On the same topic. Since I'm persisting the login, I assume it makes sense
    to store the github access token in Firebase so I can make the necessary
    API calls. I'm assuming it would be bad practice to have other user's
    access token to be shared (currently I get the list of users to display on
    a users.list state). If I wanna get the rest of the profile but hide the
    access token, I take it I would make a security rule to do that in my
    Firebase dashboard?

    Bob
    On Monday, August 11, 2014 10:28:51 AM UTC-4, Michael Kato Wulf wrote:

    Hey Bob,

    In my opinion, a service makes the most sense
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/firebase.utils.js>
    .

    Cheers,


    On Sat, Aug 9, 2014 at 6:25 PM, Bob Monteverde <bobmon...@gmail.com
    <javascript:>> wrote:
    With regards to the "var ref = new Firebase('...')" ,,, I'm thinking it
    would be pretty ugly to have that in every controller that needs the
    firebase reference. While the service will be very simple, I'm thinking
    maybe that's how I should get the ref into each controller.

    Let me know there's a different technique you guys recommend, or if the
    service s what makes the most sense.

    Bob

    On Saturday, August 9, 2014 8:46:53 PM UTC-4, Bob Monteverde wrote:

    Hey Jacob,

    Thanks again for the info, and great sum up of how security works,
    should be easy enough to go from there. I did spend time over the last
    night and day and pretty much covered everything you mentioned.

    My main question from the previous posts, which is not exactly answered
    in the docs you brought up, is more how you would go about setting up the
    base structure of the HTML, and general controller setup in Angular with
    ui-router. My original code in my second post was what I originally had.
    I have now switched over to similar to the plunkr. Basically in my index
    I have 3 named views "header", "main", and "footer". Instead of having a
    "MainCtrl" on a wrapping container to those 3, I'm using named views, and
    having a parent "root" state that every single state is a descendant of.
    Now I can set a "HeaderCtrl" that has the "currentUser" resolve, and also
    has the $scope.login and $scope.logout functions. But since the header is
    on it's own, if I need to user object in other controller, I could either
    resolve the "currentUser" in them, or if I don't need it before loading
    state, could inject the "simpleUser" service and call "$getCurrentUser"
    inside the controller. The plunker above pretty much has the structure I
    just described, just with the simpleUser service and currentUser resolve as
    described in the angularFire quick start docs.

    So back to what my question actually is. I suppose the previous set up
    I had and this set up both could do the job. But I figure it's a really
    standard setup, so if you have enough experience with Angular, I really
    just wanna know if the previous way or the way I just described (with
    minimal example in plunkr) is the more common way of setting up an app.
    Also if anything sticks out in either that sounds like I'm doing it wrong,
    or could do it better, would be great to know.

    I'll try to quickly sum up the 2 different strategies I have tried that
    I just described again above... using pseudo markup and code

    A) <container ng-controller="MainCtrl"> <header/> <main ui-view/>
    <footer/> </container>

    The MainCtrl having the Login/Logout and simpleLogin.$getCurrentUser()
    call within the controller (No resolve since the MainCtrl is not linked to
    a state here). All other top level states would be set inside the
    "<main/>" . Because all controllers are within the MainCtrl, they can
    access the user object from the MainCtrl's $scope.user.


    B) <ui-view="header" /> <ui-view="main" /> <ui-view="footer" />

    All states are descendant of "root". "root" sets the header and footer
    templates (that will be used across the app) and the header has a
    "HeaderCtrl" with a "currentUser" resolve. All descendant states are
    within the "main" ui-view. If they need the user object, they will either
    need to resolve the "currentUser" OR get it themselves view the
    "simpleLogin" service.


    Again, this is just a repeat of what I was trying to ask before, and
    attempting to summarize the 2 setups I have tried, wondering what setup is
    the "better" (well, say more common) structure. Since finding the plunkr
    that pretty much described setup "B", I'm leaning towards that way, but
    would love any input and/or changes that may be recommended to either setup
    A or B.


    And the only other real question I have, which might be only relevant to
    setup A, is... Doe's it make sense to only have a single 'var ref = new
    Firebase(...)' and maybe set that ref onto the MainCtrl's $scope so
    descendant controllers don;t need to keep making the Firebase ref?... or
    should there be a simple 1 line service for getting this ref? (that doesn't
    really sound practical, but I don't know enough to say yes or no).... OR do
    I just setup "var ref = new Firebase(...)" in every controller that I need
    the ref to access Firebase data.

    In attempt to answer my own question, the docs say that the reference
    to the new Firebase doesn;t cost much since it doesn;t make a call till I
    actually get the data, so I'm thinking I could just have "var ref = new
    Firebase(..)" at the top of each controller that I would need. But then
    again, maybe it makes sense just to have a service to get that for me.


    Thank again, hopefully I described the different options I am trying
    good enough that you can give me a good enough recommendation. I suppose
    one of the best things I could do is look at as many angular projects I can
    find to see how they do it. The header with the login function and/or user
    menu has to be a beyond common setup... which i why I'm asking questions
    like these. Trying to keep my code organized as best I can, and the more
    similar it is to how others do it, the easier it'll be to find good
    examples to base my code off of. ]


    Thanks again,and sorry for the long post, was trying my best to
    summarize the setups while still cramming enough info in there tht
    hopefully you understand the 2 different setups I have tried so far.

    Bob

    On Saturday, August 9, 2014 5:42:48 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    You are asking great questions and I am happy to help. But in the
    future, please create new threads in this Google Group for different,
    off-topic questions. That way when someone in the future searches Google
    for say "GitHub and Simple Login", they can easily find the answer and not
    have it mixed with these other questions. Thanks!

    Now, on to your questions. First I'll tackle security. Security is a
    huge deal for us here at Firebase and we think we have a come up with a
    pretty awesome solution, called Security Rules
    <https://www.firebase.com/docs/security/>. Security Rules allows you
    to define the schema of your data and who has read and write access to
    every piece of data. It is just a JSON object stored in your Firebase and
    we ensure the Security Rules on our servers, meaning they can't be bypassed
    on the client-side. Security Rules get really powerful when you combine it
    with Simple Login to create the auth variable
    <https://www.firebase.com/docs/security/guide.html#section-variable>.
    I could go on and on about Security Rules, but our documentation has a
    ton of information already about this
    <https://www.firebase.com/docs/security/>. If you read through the
    quickstart, guide, and API and still have concerns, please let me know and
    I can help you settle them. I want to assure you though that any type of
    security you could set on your data in Mongo can also be set on your data
    in Firebase. The security mechanism certainly looks a lot different, but it
    just as powerful - if not more so. One last link for you: we have a project
    called the Blaze compiler which is currently in beta which makes it even
    easier to write and test security rules. Here is a link to it on GitHub
    <https://github.com/firebase/blaze_compiler>.

    Now, to the structure of your AngularFire app. You asked a lot of
    questions and I'm unfortunately not sure I can answer them all in a
    reasonable amount of time. Let me point you to our documentation on this
    exact topic though. In our new AngularFire guide for our 0.8.0 release, we
    have a section called "Authentication
    <https://www.firebase.com/docs/web/libraries/angular/guide.html#section-angular-authentication>."
    In that section is a sub-section called "Using Simple Login With Routers."
    I have a feeling that section will explain how to combine AngularFire with
    Simple Login to get the effect you want (i.e. "clean" code and no flash of
    unauthenticated data). Essentially, you need to be using the resolve attribute
    in your route provider to get rid of the flash you are seeing. If you still
    have some questions, please don't be afraid to start a new thread and ask
    away. Please try to be specific in your questions so that we can give you
    direct answers. Sharing Plunkers are super helpful and much appreciated, so
    thank you for that!

    Good luck!
    Jacob
    On Saturday, August 9, 2014 7:39:14 AM UTC-7, Bob Monteverde wrote:

    With regards to my last post.. what do you guys think of this
    structure: http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and firebase
    simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists
    with firebase's tools?

    Thanks,

    Bob
    --
    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/432d6712-8f7e-4d03-8d70-744df188ea57%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/432d6712-8f7e-4d03-8d70-744df188ea57%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/ab7f1297-f751-4425-a8c3-a6627fcf540d%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Michael Wulf at Aug 12, 2014 at 2:44 pm
    Hey Bob,

    The primary reason to separate various features into their own modules is
    to simplify unit testing. It's considerably easier to isolate components
    and mock their dependencies if we don't have to load the entire app to do
    so. I've run into this most frequently in large scale apps, where some
    dependency can't load because it depends on a database, and now I'm forced
    to mock it and include it in each unit test set in order to get them to run
    (multiply that by 10 eccentric little services for maximum grief).

    It can be annoying, initially, to have things modularized to this level,
    but it scales well. It's also a pattern recommended by the Angular
    team--angularFire-seed is an extension of Angular's own seed project. That
    said, there are certainly alternatives. Check out Angular's many Yeoman
    generators for a bunch of them.

    Regarding GitHub token expiry, the GitHub's API docs would be the place to
    start here. A lot of OAuths put the data into the token and the tokens can
    usually be opened up with a little magic coding, or their API queried to
    ask for the expiration.

    Regarding storing the key, you would do well to split your private data and
    public data into different paths
    <https://www.firebase.com/docs/web/guide/structuring-data.html>. In
    practice, it's difficult to iterate data which is partially public and
    partially private because security rules are not filters
    <https://www.firebase.com/docs/security/guide.html#section-filter>.

    Cheers,

    On Tue, Aug 12, 2014 at 6:14 AM, Bob Monteverde wrote:

    On the same topic. Since I'm persisting the login, I assume it makes
    sense to store the github access token in Firebase so I can make the
    necessary API calls. I'm assuming it would be bad practice to have other
    user's access token to be shared (currently I get the list of users to
    display on a users.list state). If I wanna get the rest of the profile but
    hide the access token, I take it I would make a security rule to do that in
    my Firebase dashboard?

    Bob
    On Monday, August 11, 2014 10:28:51 AM UTC-4, Michael Kato Wulf wrote:

    Hey Bob,

    In my opinion, a service makes the most sense
    <https://github.com/firebase/angularfire-seed/blob/master/app/js/firebase.utils.js>
    .

    Cheers,


    On Sat, Aug 9, 2014 at 6:25 PM, Bob Monteverde <bobmon...@gmail.com>
    wrote:
    With regards to the "var ref = new Firebase('...')" ,,, I'm thinking it
    would be pretty ugly to have that in every controller that needs the
    firebase reference. While the service will be very simple, I'm thinking
    maybe that's how I should get the ref into each controller.

    Let me know there's a different technique you guys recommend, or if the
    service s what makes the most sense.

    Bob

    On Saturday, August 9, 2014 8:46:53 PM UTC-4, Bob Monteverde wrote:

    Hey Jacob,

    Thanks again for the info, and great sum up of how security works,
    should be easy enough to go from there. I did spend time over the last
    night and day and pretty much covered everything you mentioned.

    My main question from the previous posts, which is not exactly answered
    in the docs you brought up, is more how you would go about setting up the
    base structure of the HTML, and general controller setup in Angular with
    ui-router. My original code in my second post was what I originally had.
    I have now switched over to similar to the plunkr. Basically in my index
    I have 3 named views "header", "main", and "footer". Instead of having a
    "MainCtrl" on a wrapping container to those 3, I'm using named views, and
    having a parent "root" state that every single state is a descendant of.
    Now I can set a "HeaderCtrl" that has the "currentUser" resolve, and also
    has the $scope.login and $scope.logout functions. But since the header is
    on it's own, if I need to user object in other controller, I could either
    resolve the "currentUser" in them, or if I don't need it before loading
    state, could inject the "simpleUser" service and call "$getCurrentUser"
    inside the controller. The plunker above pretty much has the structure I
    just described, just with the simpleUser service and currentUser resolve as
    described in the angularFire quick start docs.

    So back to what my question actually is. I suppose the previous set up
    I had and this set up both could do the job. But I figure it's a really
    standard setup, so if you have enough experience with Angular, I really
    just wanna know if the previous way or the way I just described (with
    minimal example in plunkr) is the more common way of setting up an app.
    Also if anything sticks out in either that sounds like I'm doing it wrong,
    or could do it better, would be great to know.

    I'll try to quickly sum up the 2 different strategies I have tried that
    I just described again above... using pseudo markup and code

    A) <container ng-controller="MainCtrl"> <header/> <main ui-view/>
    <footer/> </container>

    The MainCtrl having the Login/Logout and simpleLogin.$getCurrentUser()
    call within the controller (No resolve since the MainCtrl is not linked to
    a state here). All other top level states would be set inside the
    "<main/>" . Because all controllers are within the MainCtrl, they can
    access the user object from the MainCtrl's $scope.user.


    B) <ui-view="header" /> <ui-view="main" /> <ui-view="footer" />

    All states are descendant of "root". "root" sets the header and
    footer templates (that will be used across the app) and the header has a
    "HeaderCtrl" with a "currentUser" resolve. All descendant states are
    within the "main" ui-view. If they need the user object, they will either
    need to resolve the "currentUser" OR get it themselves view the
    "simpleLogin" service.


    Again, this is just a repeat of what I was trying to ask before, and
    attempting to summarize the 2 setups I have tried, wondering what setup is
    the "better" (well, say more common) structure. Since finding the plunkr
    that pretty much described setup "B", I'm leaning towards that way, but
    would love any input and/or changes that may be recommended to either setup
    A or B.


    And the only other real question I have, which might be only relevant
    to setup A, is... Doe's it make sense to only have a single 'var ref = new
    Firebase(...)' and maybe set that ref onto the MainCtrl's $scope so
    descendant controllers don;t need to keep making the Firebase ref?... or
    should there be a simple 1 line service for getting this ref? (that doesn't
    really sound practical, but I don't know enough to say yes or no).... OR do
    I just setup "var ref = new Firebase(...)" in every controller that I need
    the ref to access Firebase data.

    In attempt to answer my own question, the docs say that the reference
    to the new Firebase doesn;t cost much since it doesn;t make a call till I
    actually get the data, so I'm thinking I could just have "var ref = new
    Firebase(..)" at the top of each controller that I would need. But then
    again, maybe it makes sense just to have a service to get that for me.


    Thank again, hopefully I described the different options I am trying
    good enough that you can give me a good enough recommendation. I suppose
    one of the best things I could do is look at as many angular projects I can
    find to see how they do it. The header with the login function and/or user
    menu has to be a beyond common setup... which i why I'm asking questions
    like these. Trying to keep my code organized as best I can, and the more
    similar it is to how others do it, the easier it'll be to find good
    examples to base my code off of. ]


    Thanks again,and sorry for the long post, was trying my best to
    summarize the setups while still cramming enough info in there tht
    hopefully you understand the 2 different setups I have tried so far.

    Bob

    On Saturday, August 9, 2014 5:42:48 PM UTC-4, Jacob Wenger wrote:

    Hey Bob,

    You are asking great questions and I am happy to help. But in the
    future, please create new threads in this Google Group for different,
    off-topic questions. That way when someone in the future searches Google
    for say "GitHub and Simple Login", they can easily find the answer and not
    have it mixed with these other questions. Thanks!

    Now, on to your questions. First I'll tackle security. Security is a
    huge deal for us here at Firebase and we think we have a come up with a
    pretty awesome solution, called Security Rules
    <https://www.firebase.com/docs/security/>. Security Rules allows you
    to define the schema of your data and who has read and write access to
    every piece of data. It is just a JSON object stored in your Firebase and
    we ensure the Security Rules on our servers, meaning they can't be bypassed
    on the client-side. Security Rules get really powerful when you combine it
    with Simple Login to create the auth variable
    <https://www.firebase.com/docs/security/guide.html#section-variable>.
    I could go on and on about Security Rules, but our documentation has
    a ton of information already about this
    <https://www.firebase.com/docs/security/>. If you read through the
    quickstart, guide, and API and still have concerns, please let me know and
    I can help you settle them. I want to assure you though that any type of
    security you could set on your data in Mongo can also be set on your data
    in Firebase. The security mechanism certainly looks a lot different, but it
    just as powerful - if not more so. One last link for you: we have a project
    called the Blaze compiler which is currently in beta which makes it even
    easier to write and test security rules. Here is a link to it on
    GitHub <https://github.com/firebase/blaze_compiler>.

    Now, to the structure of your AngularFire app. You asked a lot of
    questions and I'm unfortunately not sure I can answer them all in a
    reasonable amount of time. Let me point you to our documentation on this
    exact topic though. In our new AngularFire guide for our 0.8.0 release, we
    have a section called "Authentication
    <https://www.firebase.com/docs/web/libraries/angular/guide.html#section-angular-authentication>."
    In that section is a sub-section called "Using Simple Login With Routers."
    I have a feeling that section will explain how to combine AngularFire with
    Simple Login to get the effect you want (i.e. "clean" code and no flash of
    unauthenticated data). Essentially, you need to be using the resolve attribute
    in your route provider to get rid of the flash you are seeing. If you still
    have some questions, please don't be afraid to start a new thread and ask
    away. Please try to be specific in your questions so that we can give you
    direct answers. Sharing Plunkers are super helpful and much appreciated, so
    thank you for that!

    Good luck!
    Jacob
    On Saturday, August 9, 2014 7:39:14 AM UTC-7, Bob Monteverde wrote:

    With regards to my last post.. what do you guys think of this
    structure: http://plnkr.co/edit/oTjf0PIpxZE272TTLMhZ?p=preview
    On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:

    I got authentication working with firebase, angularFire, and
    firebase simple login.

    I'd like to be able to access and write to the user's Gists.

    Is there a way to make Github API calls to get and write the Gists
    with firebase's tools?

    Thanks,

    Bob
    --
    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/432d6712-8f7e-4d03-8d70-
    744df188ea57%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/432d6712-8f7e-4d03-8d70-744df188ea57%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/ab7f1297-f751-4425-a8c3-a6627fcf540d%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/ab7f1297-f751-4425-a8c3-a6627fcf540d%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%3Dpfvs%3D0LYy%2B34v5ZNo_q95%2B5cVruAGvM9LQ7wxAwvGhPg%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupfirebase-angular @
postedAug 8, '14 at 7:36p
activeAug 12, '14 at 2:44p
posts13
users4

People

Translate

site design / logo © 2021 Grokbase