Dealing with User passwords

Showing 1-35 of 35 messages
Dealing with User passwords jerry hamby 8/8/12 7:06 PM

After learning about the "user" collection today, I decided to try and build some User entities.


I passed down username and password. Only username shows up anywhere in the returned results,

and doing a GET on a user shows nothing. I assume it has to do with something called "Usergrid credentials vault".


I see some docs on setting passwords here:

http://apigee.com/docs/content/user 

But it only talks about doing a POST to change old password to new password.

This is all the information I can find.


How do you handle the following 2 uses cases?

1- "forgotten login info" : Sending a user his login info by email. I see no method for acquiring the User's current password.

2- admin needs to see the oldPassword manually


Is there some additional docs explaining User passwords, other than the link I mentioned above?

Re: [usergrid] Dealing with User passwords Tim Anglade 8/9/12 8:20 AM
Hi Jerry,

storing passwords in a way that allows an administrator, the user or the system to share it again in plain text is deemed to be a security risk. There’s even a Tumblr dedicated to this anti-pattern, that contains helpful background info on why the features you describe can be a bad idea: http://plaintextoffenders.com/about/

We strongly feel like it is best practice not to let anybody — ever — see your password, as part of our goal is to provide developers with a strong, secure platform. I would recommend you deal with each scenario you outlined as follows.

1. You should instead invite the user to reset is password, as do a lot of modern sites. The flow looks a bit like this: ask the user to provide his email address. Check that said email address exists in your users collection, and email the user with a link to reset his password. The link should take the user to a page that lets him pick a completely new password, which you should store in Usergrid straight away.
2. We don’t recommend you let admins see users’ passwords (people may be using the same password on other sites, etc.). If absolutely necessary you can give your admins the right to see any users’ data, or have them overwrite a user’s password.

I hope that helps. Please let us know if you have any questions!

(I also wanted to note that we have not forgotten your other inquiry :) We should have an answer out to you soon!)

Cheers,
Tim

-- You received this message because you are subscribed to the Google Groups Usergrid group. To post to this group, send email to user...@googlegroups.com. To unsubscribe from this group, send email to usergrid+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/usergrid?hl=en
 
Learn more about Apigee Usergrid at http://apigee.com/about/products/usergrid
 
Fork Usergrid on GitHub: https://github.com/usergrid/stack

Re: [usergrid] Dealing with User passwords wingy 8/9/12 10:26 AM
It seems that this requires us to have our own backend server to be able to reset our users password (since it requires organization/application/admin credentials).

I guess all apps need this feature. Would it be an appropriate feature for Usergrid to implement so we don't need a backend for this?

Eg.

1. App sends a HTTP request for resetting password for a user with email provided.
2. Usergrid sends email to user.
3. User clicks on resetting password link and is redirected to the app.
4. User fills in the new password.
5. App sends the new password.

Thoughts?

Johnny
Re: [usergrid] Dealing with User passwords Rod Simpson 8/9/12 11:05 AM
Johnny,

I think you are looking for something like this page:

http://api.usergrid.com/<myorg>/<myapp>/users/resetpw

If you embed this page in your app, users can use it to reset their passwords.

We do have a task on the roadmap for enhancing this feature a bit to make it easier to customize, however, I don't know when it is due to be released.

Rod





Rod Simpson
apigee
skype: rockerston
twitter: rockerston
m: 303.859.7323
On 8/9/12 11:26 AM, wingy wrote:
It seems that this requires us to have our own backend server to be able to reset our users password (since it requires organization/application/admin credentials).

I guess all apps need this feature. Would it be an appropriate feature for Usergrid to implement so we don't need a backend for this?

Eg.

1. App sends a HTTP request for resetting password for a user with email provided.
2. Usergrid sends email to user.
3. User clicks on resetting password link and is redirected to the app.
4. User fills in the new password.
5. App sends the new password.

Thoughts?

Johnny

On Thursday, August 9, 2012 5:20:37 PM UTC+2, Tim Anglade wrote:
Hi Jerry,

storing passwords in a way that allows an administrator, the user or the system to share it again in plain text is deemed to be a security risk. There�s even a Tumblr dedicated to this anti-pattern, that contains helpful background info on why the features you describe can be a bad idea:�http://plaintextoffenders.com/about/

We strongly feel like it is best practice not to let anybody � ever � see your password, as part of our goal is to provide developers with a strong, secure platform. I would recommend you deal with each scenario you outlined as follows.

1. You should instead invite the user to reset is password, as do a lot of modern sites. The flow looks a bit like this: ask the user to provide his email address. Check that said email address exists in your users collection, and email the user with a link to reset his password. The link should take the user to a page that lets him pick a completely new password, which you should store in Usergrid straight away.
2. We don�t recommend you let admins see users� passwords (people may be using the same password on other sites, etc.). If absolutely necessary you can give your admins the right to see any users� data, or have them overwrite a user�s password.

I hope that helps. Please let us know if you have any questions!

(I also wanted to note that we have not forgotten your other inquiry :) We should have an answer out to you soon!)

Cheers,
Tim

On Wed, Aug 8, 2012 at 7:06 PM, jerry hamby <jerry...@gmail.com> wrote:

After learning about the "user" collection today, I decided to try and build some User entities.


I passed down username and password. Only username shows up anywhere in the returned results,

and doing a GET on a user shows nothing. I assume it has to do with something called "Usergrid credentials vault".


I see some docs on setting passwords here:

http://apigee.com/docs/content/user�

But it only talks about doing a POST to change old password to new password.

This is all the information I can find.


How do you handle the following 2 uses cases?

1- "forgotten login info" : Sending a user his login info by email. I see no method for acquiring the User's current password.

2- admin needs to see the oldPassword manually


Is there some additional docs explaining User passwords, other than the link I mentioned above?

-- You received this message because you are subscribed to the Google Groups Usergrid group. To post to this group, send email to user...@googlegroups.com. To unsubscribe from this group, send email to usergrid+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/usergrid?hl=en
�

Learn more about Apigee Usergrid at http://apigee.com/about/products/usergrid
�

Fork Usergrid on GitHub: https://github.com/usergrid/stack

-- You received this message because you are subscribed to the Google Groups Usergrid group. To post to this group, send email to user...@googlegroups.com. To unsubscribe from this group, send email to usergrid+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/usergrid?hl=en
�

Learn more about Apigee Usergrid at http://apigee.com/about/products/usergrid
�

Fork Usergrid on GitHub: https://github.com/usergrid/stack

Re: [usergrid] Dealing with User passwords jerry hamby 8/9/12 11:06 AM

OK, rather than sending a user his old password, by email verification, you are suggesting the user must select a new password, correct? 

Is so, taking an example from your docs, would you just drop the old password part of the REST statement:

POST http://api.usergrid.com/my-org/my-app/users/john.doe/password {"newpassword":"foo9876a"}


So that means its a 2 step process for a user to keep his old password:

  a- select new password 

  b- reset the new password back to the old password (if they can remember it by now)


Also,  if it's "absolutely necessary" as you said, how does admin(me) get the right to see the User's old password? 


I know I can create a custom password field, but I would like to use as much of UserGrid's features as possible.

As an admin I believe in security, but I want to see all of my data.

Re: Dealing with User passwords wingy 8/9/12 11:09 AM
Didn't know it existed.

Where can I read more about it?

Johnny
Re: [usergrid] Dealing with User passwords wingy 8/9/12 11:22 AM
Yes. I need more info about it to know how to handle the whole process:

1. What query string parameters/body should I send to it.

2. What response will I get back.

3. What to do with that response.

Thanks.

Johnny
Re: [usergrid] Dealing with User passwords wingy 8/9/12 11:25 AM
I don't think seeing the old password of a user is a good feature.

In fact that could scare away users from your site if they ever found out that you can look at their passwords.

Just setting a new one if they forgot their old one is really convenient and appropriate.

Johnny
Re: [usergrid] Dealing with User passwords Rod Simpson 8/9/12 11:30 AM
You just embed the link below in an <iframe> tag and put it on your site.  There is nothing to send / nothing to get back.  This will allow the user to change their password.  It isn't an endpoint that you call via API.  It is a page that is served up.

Click on this link to see the page:

http://api.usergrid.com/apigee/sandbox/users/resetpw



Rod




Rod Simpson
apigee
skype: rockerston
twitter: rockerston
m: 303.859.7323
Re: [usergrid] Dealing with User passwords Tim Anglade 8/9/12 11:36 AM
Hi Jerry.

On Thu, Aug 9, 2012 at 11:06 AM, jerry hamby <jerry...@gmail.com> wrote:

OK, rather than sending a user his old password, by email verification, you are suggesting the user must select a new password, correct? 

Is so, taking an example from your docs, would you just drop the old password part of the REST statement:

POST http://api.usergrid.com/my-org/my-app/users/john.doe/password {"newpassword":"foo9876a"}


So that means its a 2 step process for a user to keep his old password:

  a- select new password 

  b- reset the new password back to the old password (if they can remember it by now)


Also,  if it's "absolutely necessary" as you said, how does admin(me) get the right to see the User's old password? 


You still wouldn’t be able to see the password (again, nobody can, not even us). What you could do with any Usergrid Administrator account (or an App User account tagged with the “Admin” Role), is to overwrite a user’s password with something you chose yourself (and hence, would know). It’s the closest you can get to knowing someone’s password, I believe.
 

I know I can create a custom password field, but I would like to use as much of UserGrid's features as possible.

As an admin I believe in security, but I want to see all of my data.


I would argue that the two parts of your sentence are in direct collision. Good password security means only your users know what their password is. Here’s a couple more links on the topic:

Cheers,
Tim
Re: [usergrid] Dealing with User passwords jerry hamby 8/9/12 12:15 PM
So why do I even need password for logging in or at all?
I can just do this and get the User's result data:
(johndoe was provided by the user at login time)

Does it work differently outside of the sandbox?
Re: [usergrid] Dealing with User passwords Rod Simpson 8/9/12 12:18 PM
Yes,

The sandbox app has the permissions set to full access on the Guest account by default.� A production account would not have this, so the /users/myuser call would require a Bearer Token.


Rod


Rod Simpson
apigee
skype: rockerston
twitter: rockerston
m: 303.859.7323
On 8/9/12 1:15 PM, jerry hamby wrote:
So why do I even need password for logging in or at all?
I can just do this and get the User's result data:
(johndoe was provided by the user at login time)

Does it work differently outside of the sandbox?



On Thursday, August 9, 2012 11:36:29 AM UTC-7, Tim Anglade wrote:
Hi Jerry.

On Thu, Aug 9, 2012 at 11:06 AM, jerry hamby <jerry...@gmail.com> wrote:

OK, rather than sending a user his old password, by email verification, you are suggesting the user must select a new password, correct?�

Is so, taking an example from your docs, would you just drop the old password part of the REST statement:

POST http://api.usergrid.com/my-org/my-app/users/john.doe/password {"newpassword":"foo9876a"}


So that means its a 2 step process for a user to keep his old password:

� a- select new password�

� b- reset the new password back to the old password (if they can remember it by now)


Also,� if it's "absolutely necessary" as you said, how does admin(me) get the right to see the User's old password?�


You still wouldn�t be able to see the password (again, nobody can, not even us). What you could do with any Usergrid Administrator account (or an App User account tagged with the �Admin� Role), is to overwrite a user�s password with something you chose yourself (and hence, would know). It�s the closest you can get to knowing someone�s password, I believe.
�

I know I can create a custom password field, but I would like to use as much of UserGrid's features as possible.

As an admin I believe in security, but I want to see all of my data.


I would argue that the two parts of your sentence are in direct collision. Good password security means only your users know what their password is. Here�s a couple more links on the topic:

Cheers,
Tim
-- You received this message because you are subscribed to the Google Groups Usergrid group. To post to this group, send email to user...@googlegroups.com. To unsubscribe from this group, send email to usergrid+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/usergrid?hl=en
�
Learn more about Apigee Usergrid at http://apigee.com/about/products/usergrid
�
Fork Usergrid on GitHub: https://github.com/usergrid/stack

Re: [usergrid] Dealing with User passwords jerry hamby 8/9/12 12:40 PM
OK, 
Excuse my lack of knowledge but what is a Bearer Token?
How do you acquire the token?
Could someone do a step-by-step walkthrough of production login?
Is there any Usergrid docs on this?

section: "Getting a user by UUID or username" 
there is no mention on the differences of sandbox and production
Re: [usergrid] Dealing with User passwords wingy 8/9/12 12:48 PM
I think this is what you are looking for: http://apigee.com/docs/content/authentication-and-access-usergrid

Johnny
Re: [usergrid] Dealing with User passwords Tim Anglade 8/9/12 12:51 PM
Hi Jerry,

a bearer token is a standard OAuth 2.0 concept for access. Basically the flow goes like this.

1. You do a GET on https://api.usergrid.com/ORG/APP/token?grant_type=password&username=USERNAME&password=PASSWORD — filling in the appropriate org, app, username and password details of course.
2. If the username & password combo is valid for this app, the response will include an access_token. Store this. It is your bearer token, and you should use it in all subsequent calls from this user, to access protected data.
3. You can now hit any protected URL this user has access to by passing the token either as a query string:
    … Or by passing is as an HTTP header. For example, in curl:
    curl -H 'Authorization: Bearer ACCESS_TOKEN' https://api.usergrid.com/ORG/APP/path/your/want/to/load

Johnny is right, this is explained in detail here: http://apigee.com/docs/content/authentication-and-access-usergrid

But you are right that this page make no mention of the sandbox app! I flagged that oversight and we should have it fixed shortly.

Anything else we can do to help you get started, please let us know!

Cheers,
Tim
Re: [usergrid] Dealing with User passwords Rod Simpson 8/9/12 12:59 PM
Jerry,

A Bearer Token, is just an OAuth token that is used to authenticate calls to the API that require authentication.  A description of how tokens are used can be found on the following page, along with a description of how to get these tokens:

http://apigee.com/docs/content/authentication-and-access-usergrid

The "sandbox" app is automatically created when you sign up for a Usergrid account - each account gets one.  It is a relatively new feature so it is not fully documented yet (that is coming).  The main difference between this account and any others that you create is that the "Guest" role has all permissions granted to it for the path "/**".  This means that you can make any call (GET, POST, DELETE, or PUT) to any Application endpoint as a Guest.  Basically it is wide open.  We do this for ease of adoption - to give developers one less thing to worry about as they begin to build their apps. 

To see the roles, go to the Usergrid Admin Portal, log in, and then choose the "Roles" section on the left hand side.  Click on the "Guest" role.  You should see that there is a permission for /**, and all actions are checked.

I'm not entirely sure what you mean by a step-by-step walkthough of production logic, but I will give it a go:

In production, you wouldn't want to give /** all permissions, but some may make sense.  For example, giving the POST role to /users will allow unauthenticated users to sign up - which can be a good thing.  In our sample Messagee app, we make use of this feature:

https://github.com/apigee/usergrid-sample-html5-messagee

(you can see messagee in action by going here:  http://apigee.github.com/usergrid-sample-html5-messagee)

How you authenticate against the API depends on what your needs are.  If you have users, then you would authenticate those users via the Application User endpoint.  You can see how this works in the Messagee Sample app I mention above. 

Best practice is to refrain from using your client secret and client id in an app that is distributed (like a pure HTML5 app) as it is easy for someone to gain access to them. 

We have a major doc revision coming up soon and it will include information about authenticating your app prior to going to production with it.  We hope to have that out soon.

Hope this helps,


Rod


Rod Simpson
apigee
skype: rockerston
twitter: rockerston
m: 303.859.7323
Re: [usergrid] Dealing with User passwords jerry hamby 8/9/12 2:28 PM
First I would like to thank everyone for their posts, Here is what I came up with.
FYI: All IDs are fake.

This seems to work just fine, but I'm still testing in the sandbox. If you see any obvious problems,
especially with production, let me know.

//================================================================================

var pBearerToken = '';


function mGetBearerToken() { 

    var ajax = new XMLHttpRequest();

    ajax.open('GET',('http://api.usergrid.com/management/token?grant_type=client_credentials&client_id=ZRM6EjUH-BB6igvrRIxOwHVwQ&client_secret=ZXA6igJ-5BH-8jeEeGvjR_5L9yCp'));

    ajax.send();

    

    ajax.onreadystatechange=function(){

        if(ajax.readyState==4 && (ajax.status==200)){

            var obj = $.parseJSON(ajax.responseText);

            pBearerToken = obj.access_token;

            mGetLogin("samjones", pBearerToken)

        }

    };

};


//================================================================================

function mGetLogin(vUserName, vBearerToken) {

    var ajax = new XMLHttpRequest();

    ajax.open('GET',('https://api.usergrid.com/myOrgName/sandbox/users/'+vUserName+'?access_token='+vBearerToken));

    ajax.send();

    

    ajax.onreadystatechange=function(){

        if(ajax.readyState==4 && (ajax.status==200)){

            var obj = $.parseJSON(ajax.responseText);

            console.log("apigee.js:: mGetLogin success obj = "+obj);   

        }

    };

};

Re: [usergrid] Dealing with User passwords Rod Simpson 8/9/12 2:39 PM
Jerry,

Your code looks like it will work, but it is not best practice.  It you put your client secret and client id in your code, then it is visible to the world since anyone can "view source" on your files.  It is harder for someone to get them if you are wrapping it in something like Phonegap, but it is still possible.

Are you not asking users to sign in with a username and password?

If you are, then you would only need one function, like this:

function mGetLogin(vUserName, vPassword) {

    var ajax = new XMLHttpRequest();

    ajax.open('GET',('https://api.usergrid.com/management/token?grant_type=password&username='+vUserName+'&password='+vPassword));

    ajax.send();

    

    ajax.onreadystatechange=function(){

        if(ajax.readyState==4 && (ajax.status==200)){

            var pBearerToken = obj.access_token;
            //do something with token       

        }

    };

};



Let me know if this make sense.


Rod




Rod Simpson
apigee
skype: rockerston
twitter: rockerston
m: 303.859.7323
Re: [usergrid] Dealing with User passwords jerry hamby 8/9/12 3:15 PM
Thanks Rod, your code works great and is more secure, although I'm in PhoneGap now, that may change later.

From a testing point of view, your code actually requires me to remember the passwords. I've created
several Users for testing purposes, and I couldn't remember their passwords. This is the reason I started this
topic about passwords, I though I could just go the Usergrid Admin Portal and see the passwords, silly me.   
Re: [usergrid] Dealing with User passwords wingy 8/9/12 6:32 PM
Shouldn't the url be


instead of

https://api.usergrid.com/management/token

since he is requiring a token for a app user, not an admin user?

Johnny
Re: [usergrid] Dealing with User passwords Rod Simpson 8/9/12 6:50 PM
Johnny,

You are correct.  Nice catch!  You are really becoming an expert at Usergrid!

The code below would only work for an admin user.  So the revised code would be:


function mGetLogin(vUserName, vPassword) {

    var ajax = new XMLHttpRequest();

    ajax.open('GET',('https://api.usergrid.com/<orgname/<appname>/token?grant_type=password&username='+vUserName+'&password='+vPassword));

    ajax.send();

    

    ajax.onreadystatechange=function(){

        if(ajax.readyState==4 && (ajax.status==200)){

            var pBearerToken = obj.access_token;
            //do something with token       

        }

    };

};


Thank you!


Rod




Rod Simpson
apigee
skype: rockerston
twitter: rockerston
m: 303.859.7323
Re: [usergrid] Dealing with User passwords Jody Franklin 9/2/12 7:07 PM
I've been playing with user password management, testing things out before I even start working on code. I've run into a few things that either don't work as documented, or otherwise just don't work. I realize some of this stuff is a moving target, and I may have just picked a really bad time to start trying, but I wanted to comment on these as they're related to this thread, and just because I've noticed it doesn't mean someone else has.

1) The references to setting a user password at http://apigee.com/docs/usergrid/content/user state that "If you are accessing an endpoint with Application-level access (rather than Application User-level access or anonymous access), then it is not necessary to provide an old password." This does not seem to be accurate. If I exclude the oldpassword part of the call then I receive the error "oldpassword and newpassword are both required". If I include oldpassword, and set it to an arbitrary value the response suggests that all is well, except it doesn't actually change the password. I get this behavior with an application level bearer token, organization level admin token, or organization level token.  The response with a fake old password is below:

Response Header:
Status Code: 200
Date: Mon, 03 Sep 2012 01:41:27 GMT
Connection: keep-alive
Content-Length: 86
Server: Apache-Coyote/1.1
Content-Type: application/json
Access-Control-Allow-Origin: chrome-extension://cokgbflfommojglbmbpenpphppikmonn
Access-Control-Allow-Credentials: true

Response Body:
{
    "action": "set user password",
    "timestamp": 1346636487771,
    "duration": 28
}

Also, the URL I referenced shows this call should be made as a POST, while the Console in the sidebar shows it as a PUT. I've tried it both ways with the same result. I have also referenced my org, app, and user by name, and by UUID with the same results. This is not in the sandbox, but in another app I created. I have tested this using the REST Console Chrome extension as well as the Shell in the Admin Console. The Admin Console Shell doesn't give any response at all other than to echo the endpoint back to me.

2) The http://api.usergrid.com/<myorg>/<myapp>/users/resetpw does work, sort of. The link does produce a form to provide email address, and the captcha, but the email you get back gives a link with does not include the org ID in the path. If I add the org ID, then use the link, it works without issue, but an end user isn't going to know to do that. At my current stage I'm actually more concerned about being able to force the user's password to a new value, than to provide the user with a recovery option, but eventually both will be needed.

If theses issues are already being addressed then I'll happily move on to other things until they are fixed. If, though, I'm just missing something, please let me know.
Re: [usergrid] Dealing with User passwords Nate McCall 9/3/12 9:52 AM
#1. no, you should be getting back a descriptive error message about
the passwords not matching.

#2. There is a known issue with APP_ID lookups which we are working,
but this may have to do with the URL construction itself.

We will investigate both of these ASAP - thank you for bringing them
up with detailed descriptions of the failures - always makes diagnosis
easier.
Re: [usergrid] Dealing with User passwords Nate McCall 9/3/12 1:07 PM
Ok, for #1 - I just verified that we are returning the correct error
message on old-password mismatch in master.

We'll have to have an internal discussion though as to were the bug is
on the later part of that - the docs or the code. I'm leaning towards
the latter.

Also, we are currently working on a "admin can update passwords for
anybody" feature. Stay tuned on that.
Re: [usergrid] Dealing with User passwords Jody Franklin 9/3/12 2:34 PM
So long as there is some way for an admin to force set a new password, I'm not as concerned about the how. I'd even be o'kay with an endpoint, or param for an endpoint that triggers the password reset email to be sent to a specific user, once the reset emails are generating proper URLs.
Re: [usergrid] Dealing with User passwords Dino Chiesa 9/15/12 4:14 PM
This is still a problem for me.  When I tickle the URL
http://api.usergrid.com/myorg/myapp/users/resetpw

..and enter my email address in the resulting form, I get an email, with a link like this:

https://api.usergrid.com/70444a43-e738-eee1-65f6-12345678ddd/users/7e73115d-ff71-eee1-bf27-12313b0c5ebb/resetpw?token=ZW0tghQz0f-JEeGxyhIxZZ2BLdCH_OhiUBFOlwnMaY-LJwWc

Clicking this link  results in an error like this:

    {"error":"organization_application_not_found",
     "timestamp":1347750550867,
     "duration":0,
     "exception":"org.usergrid.rest.exceptions.OrganizationApplicationNotFoundException",
     "error_description":"Could not find application for 70444a43-e738-eee1-65f6-12345678ddd/users from URI: 70444a43-e738-eee1-65f6-12345678ddd/users/7e73115d-ff71-eee1-bf27-12313b0c5ebb/resetpw"}

But if I go to

https://api.usergrid.com/myorg/myapp/users/7e73115d-ff71-eee1-bf27-12313b0c5ebb/resetpw?token=ZW0tghQz0f-JEeGxyhIxZZ2BLdCH_OhiUBFOlwnMaY-LJwWc

...then I get a reset password form. 


On Monday, September 3, 2012 9:52:54 AM UTC-7, zznate wrote:
#1. no, you should be getting back a descriptive error message about
the passwords not matching.

#2. There is a known issue with APP_ID lookups which we are working,
but this may have to do with the URL construction itself.

We will investigate both of these ASAP - thank you for bringing them
up with detailed descriptions of the failures - always makes diagnosis
easier.


On Sun, Sep 2, 2012 at 7:07 PM, Jody Franklin <jodyfr...@gmail.com> wrote:
> I've been playing with user password management, testing things out before I
> even start working on code. I've run into a few things that either don't
> work as documented, or otherwise just don't work. I realize some of this
> stuff is a moving target, and I may have just picked a really bad time to
> start trying, but I wanted to comment on these as they're related to this
> thread, and just because I've noticed it doesn't mean someone else has.
>
> 1) The references to setting a user password at
> http://apigee.com/docs/usergrid/content/user state that "If you are
> accessing an endpoint with Application-level access (rather than Application
> User-level access or anonymous access), then it is not necessary to provide
> an old password." This does not seem to be accurate. If I exclude the
> oldpassword part of the call then I receive the error "oldpassword and
> newpassword are both required". If I include oldpassword, and set it to an
> arbitrary value the response suggests that all is well, except it doesn't
> actually change the password. I get this behavior with an application level
> bearer token, organization level admin token, or organization level token.
> The response with a fake old password is below:
>
> Response Header:
> Status Code: 200
> Date: Mon, 03 Sep 2012 01:41:27 GMT
> Connection: keep-alive
> Content-Length: 86
> Server: Apache-Coyote/1.1
> Content-Type: application/json
> Access-Control-Allow-Origin:
> chrome-extension://cokgbflfommojglbmbpenpphppikmonn
> Access-Control-Allow-Credentials: true
>
> Response Body:
> {
>     "action": "set user password",
>     "timestamp": 1346636487771,
>     "duration": 28
> }
>
> Also, the URL I referenced shows this call should be made as a POST, while
> the Console in the sidebar shows it as a PUT. I've tried it both ways with
> the same result. I have also referenced my org, app, and user by name, and
> by UUID with the same results. This is not in the sandbox, but in another
> app I created. I have tested this using the REST Console Chrome extension as
> well as the Shell in the Admin Console. The Admin Console Shell doesn't give
> any response at all other than to echo the endpoint back to me.
>
> 2) The http://api.usergrid.com/<myorg>/<myapp>/users/resetpw does work, sort
> of. The link does produce a form to provide email address, and the captcha,
> but the email you get back gives a link with does not include the org ID in
> the path. If I add the org ID, then use the link, it works without issue,
> but an end user isn't going to know to do that. At my current stage I'm
> actually more concerned about being able to force the user's password to a
> new value, than to provide the user with a recovery option, but eventually
> both will be needed.
>
> If theses issues are already being addressed then I'll happily move on to
> other things until they are fixed. If, though, I'm just missing something,
> please let me know.
>
> -- You received this message because you are subscribed to the Google Groups
> Usergrid group. To post to this group, send email to
> user...@googlegroups.com. To unsubscribe from this group, send email to
> usergrid+u...@googlegroups.com. For more options, visit this group at
> https://groups.google.com/d/forum/usergrid?hl=en
>
> Learn more about Apigee Usergrid at
> http://apigee.com/about/products/usergrid
>
> Fork Usergrid on GitHub: https://github.com/usergrid/stack
Re: [usergrid] Dealing with User passwords Nate McCall 9/17/12 10:15 AM
We have a release coming out in the next day or so (awaiting QA for a
few things yet) which will address this. We'll reply when it is
available. Thanks for your patience.
Re: [usergrid] Dealing with User passwords Tim Anglade 9/27/12 3:39 PM
Hi guys, just wanted to loop back on this and say that we did deploy a fix for this earlier this week but unfortunately it hasn’t fully resolved the situation. We’ll be getting a full patch deployed soon so you can use the reset password functionality. Our apologies for the delay!

Cheers,
Tim
Re: [usergrid] Dealing with User passwords jerry hamby 12/18/12 2:56 PM
Can you update us on this?
Are there any doc links?
I just tried a link provided by Rod and I can't get to work:

Jerry
Re: [usergrid] Dealing with User passwords Rod Simpson 12/18/12 3:09 PM
Jerry,

The link that is returned in the email has the orgname in twice.  The fix was delayed , but we actually have an engineer working on it for this sprint. We should be deploying the update soon.  I will let you know when it is out.

In the meantime, if you want to test, just remove the extra orgname from the link that comes in the email.

Rod


Rod Simpson
apigee 
skype: rockerston 
twitter: rockerston 
m: 303.859.7323

From: jerry hamby <jerry...@gmail.com>
Reply-To: <user...@googlegroups.com>
Date: Tuesday, December 18, 2012 3:56 PM
To: <user...@googlegroups.com>
Subject: Re: [usergrid] Dealing with User passwords
Re: [usergrid] Dealing with User passwords Jeffrey Mock 2/4/13 10:32 PM
Hi Rod, Tim,

We are trying to use the reset password page for the SocialTagg app and it appears this issue is still occurring. Do you know when the fix will be coming?

Here are the steps we are trying:
  1. Go to this page, http://api.usergrid.com/tagg/tagg/users/resetpw
  2. Enter email address and fill in captcha
  3. Receive a link from Usergrid with the orgname twice, e.g., https://api.usergrid.com/tagg/tagg/tagg/users/93b6a35c-67ce-11e2-8b37-02e81ac5a17b/resetpw?token=ZW0tvT2KI29bEeKo-wLoGuZA3IWszrzIYJZ9Wztz5RsdPzV7KsZ_
  4. Correct the link by removing the extra orgname, e.g., https://api.usergrid.com/tagg/tagg/users/93b6a35c-67ce-11e2-8b37-02e81ac5a17b/resetpw?token=ZW0tvT2KI29bEeKo-wLoGuZA3IWszrzIYJZ9Wztz5RsdPzV7KsZ_
  5. Now end up at the same page as step (2) but with your email address set.
  6. Fill in captcha again and receive the same email with the broken link.
The cycle then continues...

It appears we are never able to successfully reset the password even after manually correcting the link.

Are we missing a step somewhere?

Thanks,

Jeff
Re: [usergrid] Dealing with User passwords Tim Anglade 2/12/13 6:33 PM
Jeffrey, can you confirm this was fixed with our last deploy? The links in the emails should work now.

Cheers!
Tim


--
Usergrid is an open-source platform for mobile & rich client applications. Apigee maintains a hosted version called “Apigee App Services” that’s free for developers to use.
 
Code: http://github.com/apigee/usergrid-stack
Docs: http://apigee.com/docs/usergrid
Try it free: https://apigee.com/usergrid

 
You received this message because you are subscribed to the Google Groups Usergrid group. To post to this group, send email to user...@googlegroups.com. To unsubscribe from this group, send email to usergrid+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/usergrid?hl=en
---
You received this message because you are subscribed to the Google Groups "Usergrid" group.
To unsubscribe from this group and stop receiving emails from it, send an email to usergrid+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Re: [usergrid] Dealing with User passwords dominic tobias 4/27/14 10:15 AM
Thanks Tim,

I was also wondering where the password field was going and I was of course already hashing the password before sending it to usergrid but I guess that isn't necessary. I am assuming and hoping the the password is not stored anywhere by you guys in plaintext right?

Dom

On Thursday, 9 August 2012 16:20:37 UTC+1, Tim Anglade wrote:
Hi Jerry,

storing passwords in a way that allows an administrator, the user or the system to share it again in plain text is deemed to be a security risk. There’s even a Tumblr dedicated to this anti-pattern, that contains helpful background info on why the features you describe can be a bad idea: http://plaintextoffenders.com/about/

We strongly feel like it is best practice not to let anybody — ever — see your password, as part of our goal is to provide developers with a strong, secure platform. I would recommend you deal with each scenario you outlined as follows.

1. You should instead invite the user to reset is password, as do a lot of modern sites. The flow looks a bit like this: ask the user to provide his email address. Check that said email address exists in your users collection, and email the user with a link to reset his password. The link should take the user to a page that lets him pick a completely new password, which you should store in Usergrid straight away.
2. We don’t recommend you let admins see users’ passwords (people may be using the same password on other sites, etc.). If absolutely necessary you can give your admins the right to see any users’ data, or have them overwrite a user’s password.

I hope that helps. Please let us know if you have any questions!

(I also wanted to note that we have not forgotten your other inquiry :) We should have an answer out to you soon!)

Cheers,
Tim

On Wed, Aug 8, 2012 at 7:06 PM, jerry hamby <jerry...@gmail.com> wrote:

After learning about the "user" collection today, I decided to try and build some User entities.


I passed down username and password. Only username shows up anywhere in the returned results,

and doing a GET on a user shows nothing. I assume it has to do with something called "Usergrid credentials vault".


I see some docs on setting passwords here:

http://apigee.com/docs/content/user 

But it only talks about doing a POST to change old password to new password.

This is all the information I can find.


How do you handle the following 2 uses cases?

1- "forgotten login info" : Sending a user his login info by email. I see no method for acquiring the User's current password.

2- admin needs to see the oldPassword manually


Is there some additional docs explaining User passwords, other than the link I mentioned above?

-- You received this message because you are subscribed to the Google Groups Usergrid group. To post to this group, send email to user...@googlegroups.com. To unsubscribe from this group, send email to usergrid+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/usergrid?hl=en
 
Learn more about Apigee Usergrid at http://apigee.com/about/products/usergrid
 
Fork Usergrid on GitHub: https://github.com/usergrid/stack

Re: [usergrid] Dealing with User passwords Rod Simpson 4/27/14 5:54 PM
It is encrypted using bcrypt. 11 pass, I think. 


Rod Simpson
T @rockerston
--
Usergrid is an open-source platform for mobile & rich client applications. Apigee maintains a hosted version called “Apigee App Services” that’s free for developers to use.
 
Code: http://github.com/apigee/usergrid-stack
Docs: http://apigee.com/docs/usergrid
Try it free: https://apigee.com/usergrid
 
You received this message because you are subscribed to the Google Groups Usergrid group. To post to this group, send email to user...@googlegroups.com. To unsubscribe from this group, send email to usergrid+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/usergrid?hl=en
---
You received this message because you are subscribed to the Google Groups "Usergrid" group.
To unsubscribe from this group and stop receiving emails from it, send an email to usergrid+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [usergrid] Dealing with User passwords dominic tobias 4/28/14 12:19 PM
Great that is what I was using too!
More topics »