A lot of this is still raw (it's not even on devel yet!). We'll try
to be available during the weekend -- let us know what you think.
I'm running into the exact same problem. I've tried several ways to prevent the "flash" of my login screen appearing then disappearing as the Meteor.user() returns not logged in (causing the login screen to appear), and then logged in (causing the login screen to disappear) when the user propagates up to the client. I was thinking another method similar to Meteor.startup() would be nice - it is called after the user auth system "settles" into its final state (we can then start our reactive templates there). Or, alternatively, if the user has a third, 'in progress' state we could build reactive templates to respond to that state (and show the "loading" screen). In general, I think the ideal situation though would be to have a way to "load but not render" until the auth state settles down - the time interval is short enough (less than a second) that it should not require a loading screen at all and if a loading screen can be avoided it would be the best solution.
-iain
--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To view this discussion on the web visit https://groups.google.com/d/msg/meteor-core/-/NbMfLBJ4zNIJ.
--
If we are covering up the onComplete hook by autopublishing the users table (or current user) in the accounts package, maybe we should expose the hook a different way.
--
Riiight. This all makes a lot more sense now guys. I quite didn't realise that subscriptions could be tied to more than one collection (or that collections to more than one subscription), but it does explain some of the complexity of writing a custom publish function. Is there some way to return multiple cursors from a publish function and have meteor take care of the plumbing for you?
Thanks all for the feedback!* Re: Tom's remark about a flickering login screen - I think that this issue is unrelated to loading the Users table but rather to the fact that we wait for the initial login to complete before setting the user locally (See the Meteor.startup block in https://github.com/meteor/meteor/blob/auth/packages/accounts/localstorage_token.js). I think we can change that to also store the userid in local storage and optimistically load that immediately, so that if the token had been revoked in the meanwhile you'll see the opposite flickering.Worth pointing out that with this solution, Meteor.user().name would still be undefined for a short period on pageload but it should be simple enough to write code to check that if someone wants to show a loading indicator of sorts.Does this sound like it would resolve your issue?
* Iain's comment 4: I'm not sure how much value there is in a non-style accounts-ui helper, since it would contain so little -- it would be pretty much as easy as putting your own button that calls Meteor.loginWithFacebook... I do think that your concern become much amplified once we'll have user/password login since those have much more styling involved than just adding a button. We'll definitely have to consider how to find a good middle-ground when we get there.
Hope this helps, and we'd definitely appreciate any additional feedback as it comes up..
On Wednesday, June 20, 2012 3:36:19 PM UTC-7, Avital Oliver wrote:Thanks all for the feedback!* Re: Tom's remark about a flickering login screen - I think that this issue is unrelated to loading the Users table but rather to the fact that we wait for the initial login to complete before setting the user locally (See the Meteor.startup block in https://github.com/meteor/meteor/blob/auth/packages/accounts/localstorage_token.js). I think we can change that to also store the userid in local storage and optimistically load that immediately, so that if the token had been revoked in the meanwhile you'll see the opposite flickering.Worth pointing out that with this solution, Meteor.user().name would still be undefined for a short period on pageload but it should be simple enough to write code to check that if someone wants to show a loading indicator of sorts.Does this sound like it would resolve your issue?I think that is the preferred UI solution. I think the existing behavior on the server on the other hand is what I'd prefer (defaults to no user ID until the user login is confirmed). So it's kind of opposite for client vs server. On the client, I'd like to render the UI optimistically in the logged in state, and then kick back to the login screen if the token ends up being invalid. On the server, I'd like to (especially in data publishing functions) assume the user is logged out until verified. That way the data publishes nothing to begin with, and when the auth is validated, then it publishes the data the user should see. The delay in the server publishing data to the client is perfectly acceptable and should respond reactively as if there was just a slow client/server connection.Is that possible (different defaults on client vs server)?
--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
That makes sense. I'm testing (and primarily concerned) with the server behavior as part of the publish-subscribe and method calls processes - auth needs to protect resources published and features accessed via methods. If the entire auth process is resolved before subscription or method calls, that is perfect (and matches up with what I'm seeing in my publish functions). So, question answered - I'm a satisfied customer.
A follow on question - is the core team planning on implementing an oath1 helper like the oath2 helper? Or was that something you were hoping to leave to the community? I didn't have time to work on some auth providers last weekend but I'm hoping to carve out some time this weekend to work on it. I think the obvious next biggest providers to cover would be Twitter and Yahoo - both of which use oath1. If the core team is going to provide a helper, then I'll definitely wait before tackling any oath1 services and concentrate on some other oath2 providers (LInkedIn and GitHub probably). But if an oath1 helper not in the near term plans, I'll probably try to take a crack at it if no one else is already working on it.
Can I just point out that although this solution is pretty good, there's still a fundamental problem with knowing when the subscription is complete. Here's a use case to highlight it:1) User A. logs in on two machines X. and Y. and hits 'remember me' or whatever to have the user_id saved.2) User A. deletes account on machine X.3) User A. re-opens the app on machine Y.i) Meteor.user is optimistically set to {_id: 'user_id'}ii) The Users subscription is opened.. and then completed with no data.iii) Nothing happens, Meteor.user remains at {_id: 'user_id'}
You can see there's a problem here. We are going to be stuck in whatever state we default to when a user is 'sort-of-logged-in' (ie. either loading, or logged in with no details).Sorry to keep harping on about this, but it's sort of my personal bugbear right now :)