First chunk of Meteor auth now in GitHub

4,262 views
Skip to first unread message

matt debergalis

unread,
Jun 15, 2012, 9:23:08 PM6/15/12
to meteo...@googlegroups.com
Good evening, or morning or what not!

We now have the first chunk of our authentication implemented on the
`auth` branch in GitHub (https://github.com/meteor/meteor/tree/auth).

Here are the high-level changes:

1: As part of livedata, method and subscription functions on the
server now have access to the current user ID with `this.userId()`.
This means you can limit what a method does and what data a publish
function sends to the client based on each client's login state.
Since subscriptions are long-lived, Meteor reruns a client's
subscriptions when its user ID changes (eg login or logout).

2: The "accounts" smart package defines a new Meteor.Collection
called "users". We've written two smart packages that use Facebook or
Google login services (over OAuth2) to manage the current user.

3: The "accounts-ui" smart package provides convenient chrome on the
client for login buttons {{> loginButtons}}.

As an example of these new features, we've added "private" items to
the Todos example, which can be seen at http://auth-todos.meteor.com.
Each user who is logged into todos can now mark items as private,
which no other user can see or modify. The full diff is here:
https://github.com/meteor/meteor/commit/5ac6ee0d6edbfe3cce93ad3eb50274904968f06f

A fuller description of the new accounts APIs is here:
https://github.com/meteor/meteor/wiki/Getting-started-with-Auth

One thing we could use help with right away is integrating with the
other major login services. The Google and Facebook packages use an
OAuth2 abstraction, so other OAuth2 services should be
straightforward. (Please submit auth pull requests against the auth
branch.) Other services like Twitter that use OAuth1 or other
protocols will be a bit more work. Don't worry about user/password
login -- we'll be taking care of that soon enough.

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.

cheers,
matt

Rodrigo Pavez

unread,
Jun 16, 2012, 1:14:51 AM6/16/12
to meteo...@googlegroups.com
Really cool!!. This was the feature needed to make meteor show its high-potential. 
One feature would be very useful is a way to organize circles of contacts in order to work on collaborative tasks with certain contacts.

I would like to help on this project in the future. This is going to be a very useful framework for collaborative apps.

Sunil Arora

unread,
Jun 16, 2012, 2:27:57 PM6/16/12
to meteo...@googlegroups.com
Awesome! This was exactly what I was waiting for. 

#cheers
Sunil

Mike Bannister

unread,
Jun 16, 2012, 2:31:08 PM6/16/12
to meteo...@googlegroups.com
So great, can't wait for a chance to dig into this! It's especially
exciting to see the patterns core devs use to solve problems like
this. -Mike
> --
> 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/-/yp7TwuIOCxQJ.
>
> To post to this group, send email to meteo...@googlegroups.com.
> To unsubscribe from this group, send email to
> meteor-core...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/meteor-core?hl=en.

Iain Shigeoka

unread,
Jun 16, 2012, 2:43:51 PM6/16/12
to meteo...@googlegroups.com
On Friday, June 15, 2012 6:23:08 PM UTC-7, Matt DeBergalis wrote:

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.

This is great. I've been waiting for auth to drop. Where would you like feedback? Here on this groups thread or...? Thanks

-iain

matt debergalis

unread,
Jun 18, 2012, 3:45:50 PM6/18/12
to meteo...@googlegroups.com
Here's great.
> --
> 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/-/K4oX1Z5f0L8J.

Tom Coleman

unread,
Jun 19, 2012, 8:25:13 AM6/19/12
to meteo...@googlegroups.com
Hey Matt,

The first comment I'd make is that I feel like we need a reactive function that we can call to tell if the Users collection is complete yet (i.e. what we were talking about here: http://stackoverflow.com/questions/10794555/is-there-any-way-to-know-when-an-meteor-subscription-is-valid).

A simple use case, say I want to show:

a) a 'loading' screen until I know WHETHER
b) the user is logged out: show a 'login' screen OR
c) the user is logged in: show the real page they've browsed to.

AFAIK, your only option right now is something like

{{#if currentUser}}
  {{> loginScreen}}
{{else}}
  {{> realPage}}
{{/if}}

Which of course doesn't cover a). (and will cause a weird flash of content IMO).

If there was we had a complete() function ala the stack overflow qn you could do something like:

{{#if usersComplete}}
  <as above>
{{else}}
  {{> loadingPage}}
{{/if}}

Template.foo.usersComplete = function() { return Users.complete(); };
[potentially it would make sense for this to be a global helper too].

Or am I missing something here? 

Cheers,
Tom

Iain Shigeoka

unread,
Jun 19, 2012, 12:56:45 PM6/19/12
to meteo...@googlegroups.com
+1

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

Iain Shigeoka

unread,
Jun 19, 2012, 4:09:54 PM6/19/12
to meteo...@googlegroups.com
Hi,

Initial comments (in addition to the item brought up by Tom) about the new auth changes:

1) A nice, simple, elegant design. I like how auth is implemented.
2) Overall, it is useful and seems to work well during my initial tests.
3) There are no fundamentally broken/missing functionality I could find except for the item Tom pointed out (user session transitions causing difficulties in setting up a non-flickering UI for users that are already authenticated).
4) I did find the default styling and HTML for account-ui to be difficult to integrate into existing designs. I think it would be useful to, in addition to the current 'insert buttons' template, to have other templates/variables that generates the link target and image source so those elements can be used without the buttons. Also, maybe an additional set of simpler templates that just generates a basic <a> tag with unstyled class (that would let people insert the a tag and style it themselves...

Questions:

1) Will the 'user' collection name be configurable? I'm not opposed to Meteor just taking over the collection name, but it seems like it may make integration with existing MongoDB databases potentially risky - especially if this sets the pattern for future features like auth.
2) Are the user documents "stable"? e.g. if we have other documents refer to a user by _id and the user object is updated by the auth package, will the _id stay the same?
3) The user document appears to be designed so people with the same email(s) across different services will have a single user document (linking being done by the "emails" list?). Is that the case? Or will each login for each service create a new user document and we will need to link users together via their emails? The use case being a user logs in with Google one day, then Facebook the other (both using the same email) - we would like to pull up the same profile and permissions for that user.
4) Are there plans for providing an API for linking users together (e.g. so they may have one account on one system, and another account under a different email on another but they can login and then link them so they are a single user)? I can see this being useful in the case of, for example, twitter where it is common for people to create several accounts (which are required to have separate email addresses).
5) Is it "OK" for our code to add additional properties to the user document or should we treat the user documents as read-only and store associated profile information in separate documents (in a separate collection)? If so, is there going to be naming convention we use to make sure we don't overwrite each other's properties?
6) Are there plans for, or hooks available to allow sites to request expanded permissions for authenticated users? Both Facebook and Google (and every other external auth provider) have APIs that can be authorized for additional capabilities (e.g. posting to a Facebook wall, etc). 

Thanks!

-iain

steeve

unread,
Jun 20, 2012, 12:45:13 PM6/20/12
to meteo...@googlegroups.com
Guys;

This is great news.  I have some comments but they may be invalid.  I apologize in advance if they are.

We are evaluating Meteor from a corporate/business perspective.  I think from a corporate or business point of view there is a strong need for Group or Role Based security where Users inherit the rights and access of the Group.

For example, John Doe belongs belongs to the Executive Management Group and John Doe and Jane Doe both belong to the Accounting Group.

Users inherit the rights of the Groups they belong to.

For example, the Executive Management Group can CRUD Budget documents but Accounting can only view (R) them.  But both groups can CRUD Expense documents.  

As a side note, we have built applications that go a step further and associate functions/methods ( app functionality ) with Groups as well.  In fact, we are evaluating Wakanda.org and ApplicationCraft.com to see what features they provide in these respects that are above and beyond simple CRUD.

While I do agree that document/record ownership by User is important, it is not very flexible for an Organization over a few people.  It becomes quite complex to manage WHO has access to what on a person by person basis.  I believe that most organizations rely on Groups such as Subsidiaries, Regions, Divisions, Departments and such to organization their data and the functionality associated with and on data, systems and processes.  

For example, we were evaluating Parse.com a few months ago and their sales staff asked us if we need assistance.  We said we couldn't continue in our evaluation because all of their data access and security functionality was limited by Person/User.  They recently posted this on their blog.

Maybe the auth branch supports this concept of Role Based Security (Users and Groups) or has implied support.   If it does, awesome.  If it doesn't then you might want to consider it.  I only wanted to share a point of view you might not have considered.  

Thanks
Steve


On Friday, June 15, 2012 9:23:08 PM UTC-4, Matt DeBergalis wrote:

Avital Oliver

unread,
Jun 20, 2012, 6:36:19 PM6/20/12
to meteo...@googlegroups.com
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.


* Iain's questions:
1. Yes, it will be configurable.
2. Yes, `_id` should stay the same.
3. Yes, email is the primary key for users. So Google and Facebook accounts end up with one user document. Note that we store service-specific data on `user.services.facebook` and `user.services.google`
4. Yes, we'll need to do that.
5. You should definitely add fields to the user document. Note that we have reserved a `private` subobject that by default isn't published to the client. As for namespacing, we need to generally solve that (we have namespacing issues around many other parts of the code, such as names for helpers). If you really want to be safe, I'd suggest you apply whatever judgement you use for global function names, etc, such as prefixing with "modulename-" or such.
6. Yes, we should extend the API for that.

* Steeve's comment: Meteor gives you complete control over defining access control -- it's all in your app code. For example, in Todos we just checked that the current user is the one for whom the task is marked private (https://github.com/meteor/meteor/blob/5ac6ee0d6edbfe3cce93ad3eb50274904968f06f/examples/todos/server/access_control.js). You could replace that with any other test, that may look up the groups the user is in, etc, and do the right thing. (Going forward we'll create a better API for defining such access control rules)


Hope this helps, and we'd definitely appreciate any additional feedback as it comes up..
Avital.

--
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.

Tom Coleman

unread,
Jun 20, 2012, 8:02:06 PM6/20/12
to meteo...@googlegroups.com
Hey Avital,

Yes, I see what you mean, and I can see how you fake out the user object in accounts_client.js when you think the User subscription hasn't loaded. I'm not sure if there's any security issue with storing the user's id in localStorage, but assuming not, it does seem like it will solve the problem I outlined. 

It'll be a problem if the user gets deleted on the server but the browser doesn't know about it, but I suppose the callback on the 'login' method can take care of that.

I guess it is a separate issue and deserves a separate discussion, but I do feel like the assumption made on (https://github.com/meteor/meteor/blob/auth/packages/accounts/accounts_client.js#L13) is a bit of a hack, due to there being no easy way to tell if a data subscription has loaded. It is a more general problem than "is the user logged in?" (or specifically "is there a user with this id?"), but rather "is there a matching record on the server OR is there no record OR can we not tell yet?".

As an example, supposing you want to show a 404 style page if a user tries to access the page for a resource that doesn't exists (e.g. http://beta.getleague.com/324143514515). A common problem is that even the record exists, the 404 page will flash up for a moment because the record isn't yet loaded into the collection. There's no way to answer the ternary question above (simply) on a collection.

Anyway, this is just the top point on my current list of feature requests for meteor right now. Sorry to derail the discussion a little bit.

Cheers,
Tom

David Greenspan

unread,
Jun 20, 2012, 8:15:33 PM6/20/12
to meteo...@googlegroups.com
Tom,

Does Meteor.subscribe's onComplete callback help with the general issue you raised?  My understanding is it tells you when the initial state of a collection has been realized.

-- David

Tom Coleman

unread,
Jun 20, 2012, 8:27:45 PM6/20/12
to meteo...@googlegroups.com
Hi David,

Yes, I think onComplete does do what I need, however my understanding is that I would have to do a whole bunch of boilerplate along the lines of (once for each collection):

Session.set('teams_loaded', false);
Teams = new Meteor.Collection('teams', function() { Session.set('teams_loaded', true); });

Of course there is no convention to how to do it, so no package could rely on user's having setup the correct session variable. (e.g. the router package I'm working on which shows a loading page until the collection is ready). That's why I said "simply".

What I'd like is for the subscription to do this automatically. I'd submit a patch but I'm not familiar enough with livedata to feel confident I'd get it right. I think simply adding a reactive variable to the collection (Teams.complete()?), and setting it to true (I think on line 490 of livedata_connection.js) when the sub is ready. Perhaps I'm missing something important here and it's not as easy as I think.

I'm happy to submit a PR if one of you could help me out with it.

Cheers,
Tom
--

David Greenspan

unread,
Jun 20, 2012, 8:53:58 PM6/20/12
to meteo...@googlegroups.com
I think the subtlety is that, in the general case, a subscription can write to multiple collections, and a collection can receive data from multiple subscriptions.  The concept of being "complete" is really associated with a subscription, and the subscription is the basis for expecting certain data to eventually load.  I don't think it's possible to know what collections might be affected by a subscription that has been started but hasn't loaded.

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.

-- David

Nick Martin

unread,
Jun 20, 2012, 9:29:15 PM6/20/12
to meteo...@googlegroups.com
On Wed, Jun 20, 2012 at 5:53 PM, David Greenspan <da...@meteor.com> wrote:
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.

Yeah, the users subscription is 'universal subscription', meaning a) it has no name, b) everyone gets it immediately when they connect with ddp, and c) there is no completion message to the client. We can change this to a named subscription and make the client subscribe explicitly, that way we get a completion notice which we can plumb out. Or, I _think_ we can use the response to the login RPC to signal completion, as the user subscription data is guaranteed to have hit the wire by then. Although, hrm... if there are outstanding RPCs, we may have the data, but not have written it to minimongo. More thought is required here.

I like Tom's idea of a reactive variable to watch for sub readiness. Perhaps we could put this on the return object from Meteor.subscribe, like the stop() function. That might be a better pattern than the onComplete callback.

Cheers,
-- Nick

Tom Coleman

unread,
Jun 20, 2012, 9:43:14 PM6/20/12
to meteo...@googlegroups.com
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?

I think it makes perfect sense for the handle returned by subscribe to include a complete() reactive var.

PS developers could then use the Meteor.deps.await function from here: https://github.com/meteor/meteor/pull/193 to get an onComplete callback if they wanted one. Just a thought.

Cheers,
Tom
--

Nick Martin

unread,
Jun 20, 2012, 10:28:47 PM6/20/12
to meteo...@googlegroups.com
On Wed, Jun 20, 2012 at 6:43 PM, Tom Coleman <t...@thesnail.org> wrote:
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?

Not yet, but that's definitely something that will happen. It should be easy to publish a 'join' involving multiple queries, with results to multiple collections. How exactly that will work, though... up in the air =)

Cheers,
-- Nick

Iain Shigeoka

unread,
Jun 21, 2012, 5:13:18 PM6/21/12
to meteo...@googlegroups.com
Responses inline below:

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)?

* 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.

I agree. You anticipated my concern - when the additional user/pass login is added, things get a lot more complicated. At some point (for user/pass), I assume there will be options for allowing/preventing auto-signups, forgotten password resets, etc etc which is a lot of UI to hook up or customize. (especially with validation and error indicators). Perhaps the complications will mean user/pass support has to be more of a toolkit than a 'one-button' turnkey solution?

BTW, I'm really looking forward to seeing how you tackle user/pass support in auth. It's an interesting problem.

Hope this helps, and we'd definitely appreciate any additional feedback as it comes up..

Not directly related but it seems a bit "linked": the state of third party/custom smart package guidance (and unit tests - use TinyTest?). I think auth is going to be an area where a lot of ground can be covered by the community if we can have some smart package guidance. Even if that is subject to breaking changes in future releases. As I understand the base oauth2 code, it will be fairly trivial for us to implement additional auth providers that use OAuth2. (I ran through the exercise with LinkedIn and it seems more work to document the API key/setup procedure than actually implementing the smart package itself.) However, I think it would be bad to saddle the meteor core team with upkeep on submitted smart packages since a lot of these OAuth vendors can change their details over time breaking the smart package. I understand why smart packages aren't opened up to everyone yet - but I think that finishing up the package manager to support external smart packages (ala npm) could really help with the auth system.

-iain

matt debergalis

unread,
Jun 21, 2012, 5:39:27 PM6/21/12
to meteo...@googlegroups.com
Hi Iain,

You're right about the package system -- keeping all of this in the
core repo isn't right. But in the meantime I'll front-burner PRs for
major login services like LinkedIn and Twitter (which will need
OAuth1). Auth is important enough that the maintenance hit when they
break APIs is still worth it.

cheers,
matt

> Not directly related but it seems a bit "linked": the state of third
> party/custom smart package guidance (and unit tests - use TinyTest?). I
> think auth is going to be an area where a lot of ground can be covered by
> the community if we can have some smart package guidance. Even if that is
> subject to breaking changes in future releases. As I understand the base
> oauth2 code, it will be fairly trivial for us to implement additional auth
> providers that use OAuth2. (I ran through the exercise with LinkedIn and it
> seems more work to document the API key/setup procedure than actually
> implementing the smart package itself.) However, I think it would be bad to
> saddle the meteor core team with upkeep on submitted smart packages since a
> lot of these OAuth vendors can change their details over time breaking the
> smart package. I understand why smart packages aren't opened up to everyone
> yet - but I think that finishing up the package manager to support external
> smart packages (ala npm) could really help with the auth system.
>
> -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/-/k10kUTP0fuMJ.

Iain Shigeoka

unread,
Jun 21, 2012, 8:08:23 PM6/21/12
to meteo...@googlegroups.com
Thanks Matt,

Understood. I'll see if I have some time to play with putting together some providers this weekend.

-iain

> You're right about the package system -- keeping all of this in the
> core repo isn't right. But in the meantime I'll front-burner PRs for
> major login services like LinkedIn and Twitter (which will need
> OAuth1). Auth is important enough that the maintenance hit when they
> break APIs is still worth it.
>

Avital Oliver

unread,
Jun 22, 2012, 2:18:14 PM6/22/12
to meteo...@googlegroups.com
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)?
 
Should be -- userId on the server and client are not directly linked, but (intentionally) manually updated by the accounts packages. For example, see how we deal with updating userId on the client on logout: https://github.com/meteor/meteor/blob/auth/packages/accounts/accounts_client.js 

Iain Shigeoka

unread,
Jun 22, 2012, 7:02:04 PM6/22/12
to meteo...@googlegroups.com
Great thanks. Auth has been a really interesting lesson in extending and enhancing Meteor "on top of the framework" as well as seeing the work that had to go into the core to help support it.

-iain

Nick Martin

unread,
Jun 27, 2012, 12:55:58 AM6/27/12
to meteo...@googlegroups.com
The auth branch now has the 'optimistic login' on the client as Avi described above. It now no longer flickers the login buttons on page load. The user name still flickers a little, since that isn't stored, but it is much less noticeable and distracting than the buttons flickering. Give it a whirl, and see what you think =)

-- Nick

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.

Iain Shigeoka

unread,
Jun 27, 2012, 3:50:39 PM6/27/12
to meteo...@googlegroups.com
Hi Nick,

This works great on the client! It shouldn't be too hard to code around the flicker of a missing user name. 

On the server, it appears to also work optimistically which is not what I think is 'right' - I don't want to start streaming sensitive data to the browser until I confirm the login is valid. Can we have the opposite behavior on the server - or another state (even if it's just on the server) to indicate the token is being verified? At least in my ad hoc tests, it appears that the server sees only the logged in state. (or could it be that the server isn't contacted until the client has verified the token or is the server just contacted with the client's token so client and server always have to have the same login state?)

-iain

PS - on a completely separate topic, I noticed while browsing the auth code that it's possible to hide fields returned from a find in Meteor.publish (which I assumed was possible but didn't see documented) using the 'fields' option. This isn't documented in the API docs. Is this a new feature for auth or just not documented in the API docs?

matt debergalis

unread,
Jun 27, 2012, 3:56:51 PM6/27/12
to meteo...@googlegroups.com
Ah, good catch. The limit option isn't new to the auth branch. And
yup, I forgot to document it under http://docs.meteor.com/#find --
I'll do that now.

(Oddly enough, there is an example use of limit at
http://docs.meteor.com/#meteor_publish)

cheers,
matt

Iain Shigeoka

unread,
Jun 27, 2012, 4:11:36 PM6/27/12
to meteo...@googlegroups.com
Heh. I guess that's a case of me being too focused actually helping. I was looking at the Meteor.publish() docs when setting up a publication, but when I was doing the find, I flipped back up to the Collections.find() section. My brain/eyes just skipped over where the field limit part of the publish example. :)

-iain

Nick Martin

unread,
Jun 27, 2012, 4:13:36 PM6/27/12
to meteo...@googlegroups.com
Hi Iain,

This patch shouldn't change the server behavior. The server doesn't think the user is logged in until it has received and validated the token sent from the client. The server should see the connection as not-logged-in at first, then transition to logged-in. However, this transition may be too fast to notice, since the login message is sent immediately after the connect message, and before any subscription or method calls from the client.

This does mean that the server and the client have different ideas about login status for a short window. But that's what latency compensation is all about =)

Does that answer your question? Happy to go into more detail if you have further questions.

Cheers,
-- Nick

Iain Shigeoka

unread,
Jun 27, 2012, 5:16:08 PM6/27/12
to meteo...@googlegroups.com
Hi Nick,

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.

-iain

Nick Martin

unread,
Jun 27, 2012, 5:48:24 PM6/27/12
to meteo...@googlegroups.com
On Wed, Jun 27, 2012 at 2:16 PM, Iain Shigeoka <ia...@shigeoka.com> wrote:
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.

Glad to hear it.
 
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.

An oauth1 helper is not in our near term plans. We're currently focusing on user/password support and access control patterns (turning off the default mutators). If no one in the community writes one we probably would eventually, but not for a while =)

-- Nick

Tom Coleman

unread,
Jul 3, 2012, 3:00:56 AM7/3/12
to meteo...@googlegroups.com
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 :)

Cheers guys,
Tom

Iain Shigeoka

unread,
Jul 3, 2012, 2:25:28 PM7/3/12
to meteo...@googlegroups.com
On Jul 3, 2012, at 12:00 AM, Tom Coleman wrote:

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'}

My understanding from the documentation is that step iii) should be that once the user login fails verification the user_id is reactively reset to a new, random ID. We detect our state with the following:

1) Meteor.user() === null - user is not logged in
2) typeof Meteor.user().emails === 'undefined' - user login is being verified
3) Otherwise the user is logged in and the full user object exists

Is that not correct (either the intention or the implementation)?

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 :)

I think this is important to nail down. My own project has me looking at some other items so I haven't had time to really test out the auth implementation after the changes Nick made. I'm very glad you're still harping on it. :) I'm sure I'd be asking the exact same questions in a week or two when i turn back to auth testing.

-iain

Nick Martin

unread,
Jul 3, 2012, 8:22:14 PM7/3/12
to meteo...@googlegroups.com
This is a good point!

What is supposed to happen:
i) Meteor.user is optimistically set to {_id: 'user_id'}
ii) login with reconnection token fails
iii) Meteor.user is reset to null.

However you are quite correct, the current code does not work this way. We'll fix this, making it so that a failed re-login does not result in the intermediate state persisting.

And you've also brought up another good point: what happens if User A deletes account on machine X while the same user is logged in on machine Y. We don't have a "sorry, you got logged out" indicator yet. Definitely something worth thinking about.

Cheers,
-- Nick
Reply all
Reply to author
Forward
0 new messages