Auth branch server side change a users password recipe

[steeve]

Another little snippet recipe for those interested.

If you are using auth branch you have probably noticed that the only function to change a password is the Client side 

[Client] Meteor.changePassword(oldPassword, newPassword, callback)

• callback: Function(error|null)
• Must be logged in to call this. Changes the currently logged in user.

May application has Group controller Resource ACL.  So there is an Administrators group, which can manage Groups, Group Permissions and Users (and which groups they belong to and inherit Group ACL Permissions from).  

I needed my Administrators group to have the ability to create users, edit/update and of course change passwords.

So, I whipped up this for the change password part.  Clearly unofficial.

1.  I put this in my server side Meteor.users.allow({}); for insert.  Caveat, if you aren't locking down your server side inserts, updates and removes with either checking the logged in user or using some kind of Group ACL you better otherwise this snippet will create a security breach and you don't want any OWASP violations.

2.  So, in my insert, locked down through my security stuff I do this.  

          //always set server side update time/date stamp cuz users/clients can't be trusted

          var ts = new Date();

          modifier.$set.updated = ts;

          //special case for password change

          if(modifier.$set){ //make sure this is a $set

            if(modifier.$set.password){ //make sure this is a password $set

              var services =  {};

              services.password = {};

              services.password.srp = Meteor._srp.generateVerifier( modifier.$set.password );

              modifier.$set.services = services;

              fields.splice(fields.indexOf("password"),1);

              fields.push('services');

              delete modifier.$set.password; //remove password

            }

          }

          

          return true;

I tested it on a half dozen user records with login under PasswordA, Admin changes to PasswordB, users log out and then cannot login with PasswordA but requires PasswordB...dozens of times.  Also checked Mongodb records as well.

Yes, it is hackety hackety but it does follow the lead of the auth branch core code for usage of the srp stuff.  I didn't do this as a PR on auth branch yet.  It seems business use case specific.  Two cents?  Business use case or should this be a server side feature on auth branch?  Maybe this discussion belongs in Meteor core, but since it is a recipe I thought it deserved to be in Meteor talk.

Enjoy.........

Steeve

[Avital Oliver]

Hi steeve,

Do the recent accounts email changes resolve your issue? You should be able to create accounts from server code and users can change their passwords by following the "Forgot Password" link. This is all done without an admin seeing users' passwords.

Thanks,

Avital.

Steeve

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/meteor-talk/-/lDrlHIzALbUJ.
To post to this group, send email to meteo...@googlegroups.com.
To unsubscribe from this group, send email to meteor-talk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/meteor-talk?hl=en.

[steeve]

Avital;

I haven't had a chance to look at it yet, but will soon. 

I am not using the account-ui package but rather the account-passwords package alone, so not sure if that makes a difference?

Although I am sure I will figure it out when I look at the new branch, does this...

- `Meteor.createUser` can now be called on the server, sending an enrollment link. When clicked this asks the user to set their initial password and logs them 

Click through to an accounts-ui screen or our own template view we render?  Which begs the question how does one handle that?

I will take a look at all of this though.  The only breaking change looks like how emails are being stored.  

Looks like good stuff overall though and I might take a look at implementing forgot and reset and drop the password change thing.  

Which email are notices sent to?  all of them?

Thanks

Steeve

On Friday, August 17, 2012 11:12:58 PM UTC-4, Avital Oliver wrote:

Hi steeve,

Do the recent accounts email changes resolve your issue? You should be able to create accounts from server code and users can change their passwords by following the "Forgot Password" link. This is all done without an admin seeing users' passwords.

Thanks,

Avital.

On Thu, Aug 16, 2012 at 8:02 PM, steeve <stephen...@gmail.com> wrote:

Another little snippet recipe for t hose interested.

[Avital Oliver]

Steeve, thanks for the great questions. Answers inline.

On Fri, Aug 17, 2012 at 8:37 PM, steeve <stephen...@gmail.com> wrote:

Avital;

I haven't had a chance to look at it yet, but will soon. 

I am not using the account-ui package but rather the account-passwords package alone, so not sure if that makes a difference?

Although I am sure I will figure it out when I look at the new branch, does this...

- `Meteor.createUser` can now be called on the server, sending an enrollment link. When clicked this asks the user to set their initial password and logs them 

Click through to an accounts-ui screen or our own template view we render?  Which begs the question how does one handle that?

The answer has two parts:

1. In packages/accounts-urls/url_client.js (included by accounts), the special URLs are captured and the tokens stored. In addition, _preventAutoLogin flag is set which causes logging in to be delayed. The intention that you show some dialog, and then call Meteor.accounts._enableAutoLogin() when the process is complete.

2. In your app code, you can read these tokens to display whatever dialog or page you want. accounts-ui takes care of that for you by adding simple dialogs directly in to the document body, regardless of whether you actually use {{> loginButtons}}. We'll clear this up a bit but in the meanwhile that logic is spread around login_buttons.js, such as at https://github.com/meteor/meteor/blob/auth/packages/accounts-ui/login_buttons.js#L410.

So if you aren't using {{> loginButtons}} the easiest transition plan would be to start by using accounts-ui just to get the dialogs, and then either restyle them, if that's possible or recreate them yourself copying over the appropriate login from login_buttons.js. If you try this it'd be great to see how this works out -- these parts of the solution might change. This is something we will definitely make sure to structure and document better since we want to make it easy for people to create different accounts UIs.

 

Which email are notices sent to?  all of them?

There is always a specific address in context -- Meteor.forgotPassword receives an email rather than a username and Meteor.createUser only looks at one email passed.

Hope this helps,

Avital.

 

To view this discussion on the web visit https://groups.google.com/d/msg/meteor-talk/-/56wGP8hFyDcJ.

[Stephen Cannon]

Avital;

Thanks for the answers.

Should have time to take a look at this soon. Looking forward to going over it.

Thanks
Steeve

Thanks
Stephen Cannon
Mobile: 727.386.6298
stephen...@gmail.com