Reset password not working?


#21

Good questions indeed. I am not as well versed with all of this information and would like to refer to @rickkas7’s expertise on it. As he is available, he should be able to update you with more information.


#22

Hi Matthew,

I think I’m in in the same boat as Joost. Can the answers to Joost’s questions above be posted here so other users like myself can benefit as well?

Thank you,
Ruben.


#23

Hi @rlysens,

Thanks for digging this up. Great idea on elaborating here for you and others. :slight_smile:

A “Particle User”, in this case, is someone who would sign up at https://login.particle.io/login for instance. This is a fully fledged, first-class citizen in our ecosystem with the ability to get password reset emails, add devices, create webhooks, products, etc.

A “Simple Auth” (or “Customer”) user is going to be created through an SDK of sorts ( such as the Android SDK). We only store incredibly basic information for these users and they do not have console access, etc. These users are “sub users” managed by a “Particle User” in this case.

We offer an endpoint to update “Simple Auth”/“Customer” users passwords–but how this is implemented (if at all) is up to the developer.

Password management around simple auth is all very basic endpoints to help you, the developer, associate your customers here at Particle. Actual password reset flows should rely on your own ecosystem for resetting passwords, sending reset emails, etc. That ecosystem should employ these Particle endpoints on the backend to help associate your user account with the associated simple auth account.


#24

Thanks for the information Matthew.

So the Device Setup Library has an activity to create customers and an activity to reset their passwords but the endpoint behind password reset (/v1/user/password-reset or /v1/products/{productId}/customers/reset_password?) is not working. That is very unfortunate.

I guess I could modify the password reset activity and Cloud SDK so that customers can modify their own password using the update customer password endpoint, but that only works if I change the OAuth client scope to Full Control. However that creates a pretty big security hole. Again, very unfortunate after going through all the trouble of creating OAuth clients, Access Tokens etc.

The other option is that I provide a password reset flow through a web server of my own. But the whole point of choosing Simple Auth is that I shouldn’t have to do that. From the docs:
“Simple auth is ideal for getting a Particle product up-and-running quickly. Without needing to build your own back-end, development time to creating an app to work with a Particle device is greatly reduced.”

It would be much better if password-reset wise, customer accounts would be treated as Particle user accounts. Then the /v1/user/password-reset endpoint would work just fine.


#25

Hey @rlysens,

If you’re finding an API endpoint is not working as intended, please file an issue on our Particle API JS repository, stating the issues you are facing and means to reproduce. Feel free to provide the issue here once created so that I can get attention around it with our engineering teams.


#26

OK. Since it hasn’t been decided at which level this issue should be addressed, I reported it at the highest level where the issue is visible to me, i.e. the Android SDK Device Setup Library:


#27

The same is the issue with cloud api
"PUT /v1/products/:productIdOrSlug/customers/:customerEmail"
for updating password. Returns

{
    "ok": false,
    "code": 404,
    "error": "Customer not found"
}

Where as this api "GET /v1/products/:productIdOrSlug/customers" returns all the customers.

Need to have a quick resolutions as its our live product and we have had couple of customers report this issue already.

ps. I use the right productID/Slug in the api above along with the right access_token.


#28

@rickkas7 @mstanley
Have raised a support ticket on hello@particle.io.


#29

Hi @Bluefalcon

Apologies on the delay on communications here. This issue should be resolved in an upcoming github pull request. Once it is merged and live, the 404 error should cease.

Please keep an eye out and update us accordingly. Thanks.


#30

Any tentative/probable date?


#31

It should be soon. Today at the earliest. Otherwise, in the next day or two.


#32

@Bluefalcon, would you be able to give this another try? The patch should be in production now.


#33

From postman the api is failing again with a different msmg:

{
    "ok": false,
    "error": "Missing password argument"
}

My API is as below:

PUT /v1/products/productSlug/customers/test@example.com?access_token=xxxxxxxxxxxxxxxxxxxxxx& password=newPassword HTTP/1.1
Host: api.particle.io
Content-Type: application/x-www-form-urlencoded
User-Agent: PostmanRuntime/7.15.0
Accept: */*
Cache-Control: no-cache
Postman-Token: bb40567c-af3f-4505-ad53-0d73133c66ce,c57b181b-3524-49cd-930e-2183ce0f2cad
Host: api.particle.io
accept-encoding: gzip, deflate
content-length: 
Connection: keep-alive
cache-control: no-cache

What could I be missing?


#34

Hmm.

I’m not sure. I tried reproducing this in a Node application and in Postman wasn’t able to get the same error. Somehow, password isn’t getting passed or isn’t passed in an appropriate fashion.

Here’s my code excerpt:

async function updateCustomer(productId,email,password) {
	// set url. Have case for product or no product (user's own)
	const uri = `https://api.particle.io/v1/products/${productId}/customers/${email}`;

	// request from API

	const options = {
		method: 'PUT',
		headers: {
			"Content-Type": "application/x-www-form-urlencoded"
		},
		uri,
		form: {
			access_token,
			client_id,
			client_secret,
			password,
		},
		json: true
	}


	return new Promise( (resolve,reject ) => {
		request(options, (err,response,body) => {
			if(err) {
				reject(err);
				return;
			}

			resolve(response);
		})
	})
	.catch(e => {
		throw new Error(e);
	})
}

Here’s my screenshot from Postman as well in a successful configuration.

I encourage you to provide screenshots of your configuration and setup to help dig into this further. I suspect it’s likely a client configuration issue, though.


#35

Working! My bad. Was putting it in params instead of body. Apologies. But thanks for help guys! Can close this issue unless it has other things broken which I am not aware of.


#36

I think we’re all set here. :slight_smile: If you notice anything else, feel free to let us know!