firebase reference. While the service will be very simple, I'm thinking
maybe that's how I should get the ref into each controller.
service s what makes the most sense.
On Saturday, August 9, 2014 8:46:53 PM UTC-4, Bob Monteverde wrote:
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/>
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
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.
On Saturday, August 9, 2014 5:42:48 PM UTC-4, Jacob Wenger wrote:
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
>. 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
I could go on and on about Security Rules, but our documentation has a
ton of information already about this
>. 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
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
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!
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
On Friday, August 8, 2014 12:53:37 AM UTC-4, Bob Monteverde wrote:
I got authentication working with firebase, angularFire, and firebase
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?
"Firebase + AngularJS" group.