auth branch now has passwords

[Nick Martin]

Hi all!

The auth branch now has a first cut at users with passwords. Now you don't have to rely on a third party login service like Facebook or Google, and an app with auth can work out of the box without having to configure anything.

This includes all the machinery to create new users, login with passwords, change passwords, etc. It uses the SRP protocol so the server never has a plaintext copy of a password. Additionally, the accounts-ui template has grown a dropdown-based UI for user login with passwords and creating users.

Obviously, this is still somewhat rough. In particular, don't rely on user password entries created now to work indefinitely. We may still change the format in a way that breaks backwards compatibility. Also, the loginButtons template in accounts-ui still missing a bunch of functionality, you can't change your password yet and it isn't very customizable at all.

The new API is up on the wiki: https://github.com/meteor/meteor/wiki/Getting-Started-with-Auth. The short version:

- Add the accounts-passwords package. The accounts-ui package will automatically include options for creating users and logging in with passwords.

- To restrict new user creation:

Meteor.accounts.validateNewUser(function (proposedUser) {

  ...

  return boolean; // true to accept, false to reject

});

(or if you need to control user creation more, you can also use the Meteor.accounts.onCreateUser hook)

- If you have a custom login form (not accounts-ui) use:

Meteor.loginWithPassword(user, password, callback)

Meteor.createUser(options, extra, callback)

Meteor.changePassword(oldPassword, newPassword, callback)

A couple other little changes that might be of interest to some:

- If you're working on another oauth2 provider, note that the API to registerService has changed.

- Weibo created users now store the Weibo screen name in services.weibo.screenName, not a top-level property of the user.

Feedback, please! Some specific areas that we're curious about:

- What sort of customization do you want to do to the loginButtons template?

- What sort of account restrictions are you likely to use? Everyone must have a username? Everyone must have an email?

Cheers,

-- Nick

[steeve]

Is there a way to create users server side?  

For example, suppose you want to create some initial users during startup if the particular users do not exist or if the Meteor.users collection does not exist.  An example would be say an Administrator.

I may not have seen it but the docs show how to create a user client side with Meter.createUser and and then validateNewUser and onCreateUser server side but I have been trying to create a user server side during startup similar to my above example.

Should I put this on StackOverflow or Github/Issue instead of there in this threar?

Thanks

Steeve

[steeve]

I created the question about creating users server side on stack overflow so that others may benefit when there is an answer.  I had asked the same question here but felt it probably wasn't the best place.

http://stackoverflow.com/questions/11629759/how-can-i-create-users-server-side-in-meteor

Steeve

On Tuesday, July 24, 2012 2:07:47 AM UTC-4, Nick Martin wrote:

[Nick Martin]

Good point! There is currently no good way to do this.

We should make Meteor.createUser also work on the server. The only difference would be it would not log you in as the new user on the server.

As workaround for now, you can just insert the user directly into the table. This is definitely not the right approach, but it should work:

Meteor.users.insert({username: 'foo', emails: ['b...@example.com'], name: 'baz', services: {password: {srp: Meteor._srp.generateVerifier('password')}}});

Thanks!

-- Nick

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

[steeve]

Worked like a charm.  I added your solution to SO but with caveat not long term bcuz Meteor team will probably provide a longer term solution.

Thank you so much.

Steeve

To unsubscribe from this group, send email to meteor-core+unsubscribe@googlegroups.com.

[steeve]

Another use case would be where an Administrator in an app would be creating users rather than having the user sign up ui.  Probably most typical of corporate apps.  

Although I imagine at some point there will be auth providers for LDAP or other corporate directories which would be used for auth.

[Markus Gattol]

Verification via email before account activation would be a nice optional but built-in thing to have:

 - the user provides a unique username, a password and email address

 - account is created but set inactive

 - an email containing a link to click is send to the user

 - link contains a token that's verified by the server

 - only if the link is clicked and thus the users email is verified is the account really activated

[steeve]

1.  this.userId() throws an error for me Client side.

2.  While this.userId() is available server side is there a this.User available server side?  Like access to the rest of the user collection record for 'this' on the server?

3.  How about a server side Meteor.accounts.afterLogin() that allows us to do things after login?  Like add things to the this.User collection record in session or at least be able to access the records fields without having to run an additional find/fetch.  Maybe even decline the login even though meteor has approved it? Maybe this already exists, but I only saw the this.userId() server side.

This might be particular to me.  My users have a field called groups and in it is an array of groups they belong to.  Which I am trying to use for the collection publications for things like sections, categories, articles, components, modules, menus, etc...  So, I am running a find now to get the user data.

4.  Ability to turn off new user creation in the accounts-ui package.  That way only login works but not account creation.

5.  How can we style the accounts-ui package?

6.  Maybe a preprocessing hook before account creation to allow us to define our own rules prior to account creation.  Unless Meteor.accounts.validateNewUser already does that.

7.  A server side login preprocessing hook like beforeLogin() maybe to allow us to insert custom app specific logic before login completes and ability to decline login before Meteor touches it?  Maybe this already exists.

8.  Someone else already mentioned email verification as part of the account creation process.  Worth mentioning again because a lot of web apps require that.

9.  Maybe a manual approval required after account creation.  Requires concept of admin to approve sign up requests.  Would be good for business use.

10.  Configurable options for mandatory email and/or username.  Would allow some apps to use email as username and other apps to use only username and some apps to use both.  Configurable allow login with either if they exist.

Steeve

On Tuesday, July 24, 2012 2:07:47 AM UTC-4, Nick Martin wrote:

[Iain Shigeoka]

Hi Steeve,

I'll take a stab at answers inline below. I'm just a user of auth so I may not be 100% right. :)

On Jul 26, 2012, at 6:50 AM, steeve wrote:

1.  this.userId() throws an error for me Client side.

It's a server only function.

2.  While this.userId() is available server side is there a this.User available server side?  Like access to the rest of the user collection record for 'this' on the server?

You should use this.userId() to find the user object in the users collection.

3.  How about a server side Meteor.accounts.afterLogin() that allows us to do things after login?  Like add things to the this.User collection record in session or at least be able to access the records fields without having to run an additional find/fetch.  Maybe even decline the login even though meteor has approved it? Maybe this already exists, but I only saw the this.userId() server side.

You should react to the change in user status on the client to request additional data if login status changes the data you should push to the client. Note that the server's publish/subscribe is reactive on this.userId so if you publish based on this.userId, when the user logs in, you'll get publish called again with an updated this.userId. So you can use the reactive change on the server to react to the login.

This might be particular to me.  My users have a field called groups and in it is an array of groups they belong to.  Which I am trying to use for the collection publications for things like sections, categories, articles, components, modules, menus, etc...  So, I am running a find now to get the user data.

Don't be afraid to run the find. :) Meteor would have to run the find for you to support this.User so by letting you run the find, you can pull the data you need (and leave the data you don't).

4.  Ability to turn off new user creation in the accounts-ui package.  That way only login works but not account creation.

Just return false from Meteor.accounts.validateNewUser(validator) on the server.

5.  How can we style the accounts-ui package?

I think this package is still a work in progress. In other discussions we discussed the need for styling the UI but it's something the team wants to visit in the future.

6.  Maybe a preprocessing hook before account creation to allow us to define our own rules prior to account creation.  Unless Meteor.accounts.validateNewUser already does that.

You are supposed to do that. Meteor.accounts.onCreateUser is probably a better place to do it.

7.  A server side login preprocessing hook like beforeLogin() maybe to allow us to insert custom app specific logic before login completes and ability to decline login before Meteor touches it?  Maybe this already exists.

8.  Someone else already mentioned email verification as part of the account creation process.  Worth mentioning again because a lot of web apps require that.

Agreed. I think it's on the to-do list.

9.  Maybe a manual approval required after account creation.  Requires concept of admin to approve sign up requests.  Would be good for business use.

I think you'll need to implement it by rejecting the validateNewUser but saving the data and generating the confirmation. I don't know if they're planning on making it part of the core framework since it would require too much app specific knowledge from the framework.

10.  Configurable options for mandatory email and/or username.  Would allow some apps to use email as username and other apps to use only username and some apps to use both.  Configurable allow login with either if they exist.

I think you can control that using the validation function. You don't have to use the accounts-ui form for account creation.

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

To post to this group, send email to meteo...@googlegroups.com.

To unsubscribe from this group, send email to meteor-core...@googlegroups.com.

[Nick Martin]

You are 100% right =)

A couple feedback topics inline below:

On Thu, Jul 26, 2012 at 8:19 AM, Iain Shigeoka <ia...@shigeoka.com> wrote:

Hi Steeve,

I'll take a stab at answers inline below. I'm just a user of auth so I may not be 100% right. :)

On Jul 26, 2012, at 6:50 AM, steeve wrote:

5.  How can we style the accounts-ui package?

I think this package is still a work in progress. In other discussions we discussed the need for styling the UI but it's something the team wants to visit in the future.

Very much a work in progress. This is a specific area we'd love to get feedback on!

At some point of customization, I think developers will want to just write their own UI. The lower-level API calls used by accounts-ui are pretty simple to wire up to a custom UI, and login flows are one of the most customized things in apps.

But at the same time, I expect many developers will just stick with the basic accounts-ui package for a long time if they can fit it into the overall design of their site without too much effort. So if we can add a basic level of customizability, we can save lots of people from some effort and complexity.

With that in mind, what are the things you'd want to customize? How would you like to style it? What is the first customization you'd make to it? What are customizations that if accounts-ui didn't have would force you to write your own login flow?

 

8.  Someone else already mentioned email verification as part of the account creation process.  Worth mentioning again because a lot of web apps require that.

Agreed. I think it's on the to-do list.

Yup. Next on the todo list, too =)

 

10.  Configurable options for mandatory email and/or username.  Would allow some apps to use email as username and other apps to use only username and some apps to use both.  Configurable allow login with either if they exist.

I think you can control that using the validation function. You don't have to use the accounts-ui form for account creation.

You can do all this with the validation function. We're also planning on adding some basic configuration options that both automatically add validators and control the chrome in accounts-ui. With the right options, we could save a lot of people some effort and complexity. This is also something we'd like feedback on. What are the basic accounts uses cases you'd use in your apps? (username only, email only, what else?)

Cheers,

-- Nick

[Iain Shigeoka]

On Jul 26, 2012, at 2:53 PM, Nick Martin wrote:

On Jul 26, 2012, at 6:50 AM, steeve wrote:

5.  How can we style the accounts-ui package?

I think this package is still a work in progress. In other discussions we discussed the need for styling the UI but it's something the team wants to visit in the future.

Very much a work in progress. This is a specific area we'd love to get feedback on!

With that in mind, what are the things you'd want to customize? How would you like to style it? What is the first customization you'd make to it? What are customizations that if accounts-ui didn't have would force you to write your own login flow?

I think designing the HTML to have options for easy CSS styling would be a great start. Perhaps a few options to get the HTML to be sent as a <ul> (for the list of login buttons) or a few nested div options would make it easier to style the UI to integrate with websites. Also a way to hook into the code to add additional options (say extra 'blurb' text or an extra link or button).

I guess the whole extension system for accounts-ui is a big question. Say I implement an additional login provider, how do I add the buttons etc (or is the only model to fork the original and edit the code directly). A particular use-case for me for example is we will have a 'login with google' option, but for employees, we'll want people to login with their company account - which happens to also be a google apps login. The code and login provider is the same accounts-google for the two different 'login buttons' but we want to provide different images /text for one button and auto-fill in our domain for the employee login. And although we have all the providers activated, we may only want some providers shown on some pages. I'm not sure if you want to support that deep a set of options though.

10.  Configurable options for mandatory email and/or username.  Would allow some apps to use email as username and other apps to use only username and some apps to use both.  Configurable allow login with either if they exist.

I think you can control that using the validation function. You don't have to use the accounts-ui form for account creation.

You can do all this with the validation function. We're also planning on adding some basic configuration options that both automatically add validators and control the chrome in accounts-ui. With the right options, we could save a lot of people some effort and complexity. This is also something we'd like feedback on. What are the basic accounts uses cases you'd use in your apps? (username only, email only, what else?)

We will be doing email only logins and need a password reset (forgot password) capability. We don't want to allow open account creation (all accounts must be created by an admin) but we want the setup to be mostly self-help (e.g. the admin puts in an authorized email address and the system takes over creating the rest of the account - email verification with instructions, force user to create a password, etc).

For the accounts themselves, a password validator would be great (e.g. runs a dictionary attack, enforces minimum length, variation in character types - numbers, letters, symbols, etc) as well as password expiry and forced password updating (and no re-using old passwords). Email verification as mentioned before - how to do that while keeping the bundle easy to install in any infrastructure though may be difficult.

I think those are fairly standard, expected account management features that Meteor could provide and create a lot of value.

-iain

[steeve]

I think I was confused by this line on the Getting Started with Auth page then.

[Client/Server] Within methods/subscriptions -- this.userId() returns the current user ID

and I assumed that this.userId() was available client side based on that.

To unsubscribe from this group, send email to meteor-core+unsubscribe@googlegroups.com.

[mohamed mellouki]

Hi

it would be awesome if the  auth system has its own captcha-like system built in it thats activate after x number of failed authentication, it would increase security and reduce dependency to third party services.

i don't know if its can/need to be done since meteor it isn't a MVC sys and mongodb is a noSQL db but how about an access control list system with 3 collections :

- one representing a list of users and the group they belong to.
- one representing a list of methods built in meteor like those of Meteor.Collection for example (find.insert etc.) and others defined by developers in Meteor.methods.
- and the last one stores the access status of a group/user to each methods.

its a many to many relationship between groups and actions with the actions-status added the the join table.

the user/group collection must be updated each time a user register to the system: for example when a user register, the register method in the server attribute to him the "registered" group, this group has limited access to different services (methods) due to the ACL setup, once he validate his registration sent by email which for example provide a link that access a validation method in the server in wich after validation it upgrade his status to the "member" group for example so he can have access to more services of the system. 

An admin method that monitor the Meteor.methods to check for new/removed methods and update the collection subsequently and allow the management of rights in simple way like a grid for example with a groups column and methods rows with the possibility the change the access for each group to a method with one click ex : http://www.alaxos.ch/blaxos/img/cms/acl.png

In order for it to work a flash-message system is a necessity so users know that they can't access this resource because that they don't have enough access.

if you want to have and idea about what i m talking about check the ACL system in Cakephp. Again maybe it can't be implemented or doesn't need to be.

thanks

[Mike Bannister]

Hi all,

I added some parallel packages for oauth1 (accounts-twitter,
accounts-oauth1-helpers). I have a pretty big checklist of things I
plan on improving or changing but it works pretty well at this point.

You can see it in action here

https://atmosphere.meteor.com/

You can see the code here

https://github.com/possibilities/meteor/compare/auth...oauth1

I have a lot more to say and questions to ask but I figured I'd let it
out while it's still a lil raw. One thing I do want to point out is I
kept everything needed to write an oauth1 client in a package called
`oauth1` apps can also consume oauth API's without depending on any of
the accounts-* packages. I think this should happen for oauth2 also
(e.g. user wants to share a photo on facebook but they log in with
username password). I have this and a number of other significant
refactors (involving oauth2 and oauth1) in mind that I'd be happy to
go wild on but I think this will take some coordination.

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

>
> To post to this group, send email to meteo...@googlegroups.com.
> To unsubscribe from this group, send email to

> meteor-core...@googlegroups.com.

[Nick Martin]

Hi Mohamed,

Thanks for the feedback!

A 'roles' based access control system is on our list for before auth is finalized. The current access control api is low level and lets you build whatever sort of layer on top makes sense for your app, but is not super easy and approachable. By providing a roles based API like you describe on top of the low level API, we can make the common case usage much easier.

Captchas are something we thought about, and left room for in the API, but do not plan to implement as part of the first auth release. Developers can implement captchas using the 'options' parameter in createUser and and validate it in onCreateUser. This could make a good add-on package for someone to implement on top of the accounts packages.

Cheers,

-- Nick

On Sat, Jul 28, 2012 at 6:41 PM, mohamed mellouki <mellou...@gmail.com> wrote:

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

[Nick Martin]

On Fri, Jul 27, 2012 at 2:38 PM, Iain Shigeoka <ia...@shigeoka.com> wrote:

On Jul 26, 2012, at 2:53 PM, Nick Martin wrote:

On Jul 26, 2012, at 6:50 AM, steeve wrote:

5.  How can we style the accounts-ui package?

I think this package is still a work in progress. In other discussions we discussed the need for styling the UI but it's something the team wants to visit in the future.

Very much a work in progress. This is a specific area we'd love to get feedback on!

With that in mind, what are the things you'd want to customize? How would you like to style it? What is the first customization you'd make to it? What are customizations that if accounts-ui didn't have would force you to write your own login flow?

I think designing the HTML to have options for easy CSS styling would be a great start. Perhaps a few options to get the HTML to be sent as a <ul> (for the list of login buttons) or a few nested div options would make it easier to style the UI to integrate with websites. Also a way to hook into the code to add additional options (say extra 'blurb' text or an extra link or button).

Interesting! For the HTML styling, I wonder if there is a way to do it without options, maybe there is some div structure that we could use that would allow most styling. The current code just adds enough divs to do the default styling, but if we added a lot of un-styled divs that people could add styles to maybe we don't need to provide an explicit customization hook.

Adding elements is a different matter, though, it can't be just CSS tweaking. Maybe for that we add some template helpers that can be overridden to provide additional HTML to be inserted at various places?

 

I guess the whole extension system for accounts-ui is a big question. Say I implement an additional login provider, how do I add the buttons etc (or is the only model to fork the original and edit the code directly). A particular use-case for me for example is we will have a 'login with google' option, but for employees, we'll want people to login with their company account - which happens to also be a google apps login. The code and login provider is the same accounts-google for the two different 'login buttons' but we want to provide different images /text for one button and auto-fill in our domain for the employee login. And although we have all the providers activated, we may only want some providers shown on some pages. I'm not sure if you want to support that deep a set of options though.

Interesting use case, makes sense. As you say, this specific case may fall on the 'write your own UI' side of the line, rather than adding a lot of options to accounts-ui.

 

10.  Configurable options for mandatory email and/or username.  Would allow some apps to use email as username and other apps to use only username and some apps to use both.  Configurable allow login with either if they exist.

I think you can control that using the validation function. You don't have to use the accounts-ui form for account creation.

You can do all this with the validation function. We're also planning on adding some basic configuration options that both automatically add validators and control the chrome in accounts-ui. With the right options, we could save a lot of people some effort and complexity. This is also something we'd like feedback on. What are the basic accounts uses cases you'd use in your apps? (username only, email only, what else?)

We will be doing email only logins and need a password reset (forgot password) capability. We don't want to allow open account creation (all accounts must be created by an admin) but we want the setup to be mostly self-help (e.g. the admin puts in an authorized email address and the system takes over creating the rest of the account - email verification with instructions, force user to create a password, etc).

Gotcha. Seems like a reasonable and common use case. We should make sure to support that.

 

For the accounts themselves, a password validator would be great (e.g. runs a dictionary attack, enforces minimum length, variation in character types - numbers, letters, symbols, etc) as well as password expiry and forced password updating (and no re-using old passwords). Email verification as mentioned before - how to do that while keeping the bundle easy to install in any infrastructure though may be difficult.

 

I think those are fairly standard, expected account management features that Meteor could provide and create a lot of value.

Email verification is def on the list. Password validators will have to be client side only, since the server never knows the plaintext password. This is probably OK, since if the user really wants to cheat and set a bad password they are only hurting themselves. Not reusing passwords is also a little tricksy, for the same reasons. That's def something to think about.

Thanks for the great feedback!

-- Nick

[Markus Gattol]

Email verification is def on the list. Password validators will have to be client side only, since the server never knows the plaintext password. This is probably OK, since if the user really wants to cheat and set a bad password they are only hurting themselves. Not reusing passwords is also a little tricksy, for the same reasons. That's def something to think about.

Because many people don't exactly like the hassle of running their own mailservers, maybe it makes sense to not just support that case but also a second choice out of the box where you don't have to run your own mailserver but can use an API like for example Amazon's SES

 - http://aws.amazon.com/ses

 - https://github.com/appsattic/node-awssum/tree/master/examples/amazon/ses

[Nick Martin]

Definitely! One of the requirements is that email work out of the box with 'meteor deploy' without the user having to set up a mail server, create accounts on third party services, or the like. At the same time, users who want to use existing mailservers, internal email networks, etc, must have the customization options needed to configure email to their liking.

-- Nick

[steeve]

Auth Branch rules so far and looking forward to more!  I stepped away from Meteor for a bit to explore other stacks.  Came back when this auth branch with passwords was announced.  In one week I have accomplished more than I expected and 1000 times more than I did in the weeks I was away tinkering with others stacks.  Just had to shout out to the Meteor dudes!  Totally rad!  

On Tuesday, July 24, 2012 2:07:47 AM UTC-4, Nick Martin wrote:

[steeve]

How do I remove a user with a call from the client side but not as the user whose record is being remove and then use the allow to intercept the remove so I can authenticate that an Admin is removing the user?

I tried Meteor.users.remove but it produces a 403 error.

I tried my own collection Users that publishes/subscribes to db.users through a name "allusers".  This ends up publishing to Meteor.users instead and when I call Users.remove or Users.update neither works properly.

Should we use Meteor.methods for this?

Thanks

Steeve

On Tuesday, July 24, 2012 2:07:47 AM UTC-4, Nick Martin wrote:

[Avital Oliver]

I think your options are either defining a special method, or giving explicit access for admins to remove users -- something like:

Meteor.users.allow({

  remove: function(userId, docs) {

    var user = Meteor.users.findOne(userId);

    return user && user.admin;

  }

});

Does this do what you want?

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

[steeve]

Yeah, I finally figured it out and did something similar.  Thank you though!

To unsubscribe from this group, send email to meteor-core+unsubscribe@googlegroups.com.

[steeve]

Avital;

I wrote a preLoginHook and postLoginHook inside accounts_server.js if you guys are interested.  

I needed it for the following business cases.

1.  Business applications require audit trails of user activity.  Users cannot be deleted but rather disabled (active boolean field).

2.  Business applications need to restrict login by day of week and times of day.

3.  Cannot put business logic into core Meteor code.  Meteor core auth already supports adding fields to the user record.  Hooks are required for preLogin to prevent resume and postLogin to prevent new login based on any business use case.

Here is what I did...

in accounts_server.js  CHANGED only the login method and added two hook implementations...

login: function(options) {

      if (preLoginHook)

        if(!preLoginHook(options))

          throw new Meteor.Error(403, "Login validation failed.");

      var result = tryAllLoginHandlers(options);

      if (result !== null)

        if (postLoginHook) 

          if(!postLoginHook(result))

            throw new Meteor.Error(403, "Login validation failed.");

    

        this.setUserId(result.id);

      return result;

    }

  ///

  /// CREATE PRELOGIN HOOK

  ///

  var preLoginHook = null;

  Meteor.accounts.preLogin = function (func){

    if (preLoginHook)

      throw new Error("Can only preLogin once");

    else

      preLoginHook = func;

  };

  ///

  /// CREATE POSTLOGIN HOOK

  ///

  var postLoginHook = null;

  Meteor.accounts.postLogin = function (func){

    if (postLoginHook)

      throw new Error("Can only postLogin once");

    else

      postLoginHook = func;

  };

Here is how one can implement it.  The example below only uses a Meteor.users.active boolean field but one could implement a time based (year, month, weeks, days or time of day), ip range and all sorts of business use case login restrictions.  It does not interfere with user not found or incorrect password processing.

Here is the example, server side code only for Meteor.users.active boolean field

Meteor.accounts.preLogin(function(options){

  if(options.resume){

    if(!Meteor.users.findOne({_id: options.resume.id, active: true})){

      return false;

    } else {

      return true;

    }

  } else {

    return true;

  }

  

});

Meteor.accounts.postLogin(function(result){

  if(!Meteor.users.findOne({_id: result.id, active: true})){

    return false;

  } else {

    return true;

  }

});

Then as a little side bonus I put this client side in the auto-subscribe.

if(Meteor.user().active == false)

        Meteor.logout();

I would rather have a way to log the user out server side when I set the Meteor.users.active = false; but I haven't quite figured out how to do that yet.

As well, I have a Group Resource based ACL system built if you are interested as well.  Resources can be collections, menus, menu items, pages or whatever you really want I guess.  Users are assigned to one or more Groups.  Groups are assigned to one ore more Resource.  Resources have the following acl fields controlling access  acl_group_fetch:  [], acl_group_insert: [], acl_group_update: [], acl_group_remove: [] Users inherit the Group rights.

An example implement on the allow looks something like...

Todos.allow({

    insert: function (userId, doc) { 

      if( Sections.find({

        controller: 'todos', //or could be a controller name if sharing it server/client like Meteor.request.controller 

        acl_group_insert: {

          $in: Meteor.users.findOne( { _id: userId }, { fields: { groups:1 } }).groups //user_groups_selector

        }

      }).count() > 0 ){

        return true;

      }else {

        return false;

      } 

    }

});

Finally, if a preLogin or postLogin hook doesn't make it into the auth with passwords, is it safe or proper for me to carve out a copy and make it my own loginHandler?

Thanks

Steeve

 

On Monday, August 6, 2012 3:31:19 PM UTC-4, Avital Oliver wrote:

To unsubscribe from this group, send email to meteor-core+unsubscribe@googlegroups.com.

[steeve]

Avital;

This has a bug.  options.resume.id does not exist in options on the preLogin hook.  Not sure how I overlooked that.  the user._id doesn't exist in options.resume so I had to change my preLogin hook to the following.  A bit kludgy because it relies on going into Meteor core code.  I will have to figure out something better.  Still in concept it works.

Meteor.accounts.preLogin(function(options){

  if( options.resume ){

    var loginToken = Meteor.accounts._loginTokens.findOne({_id: options.resume});

    if (loginToken){

      if(!Meteor.users.findOne({_id: loginToken.userId, active: true})){

        return false;

      } 

    }

  } 

  return true;

});

[Kaoru Aoi]

Really need an edit account button after logging in.

Also more generally need a way to modify smart packages from user land.

On Tuesday, July 24, 2012 2:07:47 AM UTC-4, Nick Martin wrote:

[Avital Oliver]

I agree that we should allow app developers to build their own packages, and potentially augment existing ones (though it's actually really hard to imagine what this interface would be like). Specifically, accounts-ui could support adding additional buttons.

What would you like the edit account button to do? Change username?

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

To post to this group, send email to meteo...@googlegroups.com.

To unsubscribe from this group, send email to meteor-core...@googlegroups.com.

[Tom Coleman]

I should point out as well that meteorite will currently override meteor core packages with custom packages that have the same name.

So for instance you could make a local accounts-ui package and if you include it in your smart.json mrt will use it rather than the package included in meteor core.

Cheers,

Tom

[Kaoru Aoi]

How about something like spark?

I'm trying to replace that, that's probably a different level of core right.

Any way to get that working?

[Kaoru Aoi]

I think just linking to a profile edit page would be a good start, we can customize it further from there. Also would be really nice if accounts-ui used the bootstrap classes by default.

[Tom Coleman]

No, actually most of core is in packages, so theoretically, there's no reason you couldn't modify the spark package. 

However if you start messing with core you might be better off just forking meteor, as the overriding packages trick will probably get pretty annoying if you need to change a few. 

To view this discussion on the web visit https://groups.google.com/d/msg/meteor-core/-/7eIj3T4yW38J.