Use oauth?

[ostinelli]

Hello @Pmant! Let me introduce myself, I am Roberto Ostinelli, Neato Robotics' Director of Cloud Services.

I'm impressed with the work that you've put into integrating with our robots! Great job!

Given the interest that we've seen from developers like yourself and around the forums we've listened and have just released the Neato Developer Network. In there, amongst other things you will find official documentation and SDKs for JavaScript, iOS and Android (for now, we plan on expanding to other languages too!).

This issue is for you to consider switching to proper OAuth instead of the internal logins mechanisms that you are using in this gem. BTW these mechanisms and other things have already been integrated in the official Neato JavaScript SDK, so maybe all this needs is a port to node?

It would be the official way to proceed, and you would avoid some improper implementations. For example, you should not pass token and platform here: they are not needed, raise errors on our systems - since tokens are invalid - and this could eventually result in the blocking of user accounts by our automated systems if abused. We definitely wouldn't want that!

Please note that all of this is in Beta, we're a small team but are doing our best!

All the best, r.

PS: I've opened the same issue on the gem that, to my knowledge, started it all. :)

[Swiftnesses]

This would be great, I don't have the skills to convert the official SDK to node, perhaps someone else would be kind enough to look at it?

[wronex]

@ostinelli from what I understand your OAuth2 workflow is not compatible with efforts such as node-botvac. Since you require a fixed redirect_uri (that points to a HTTPS address non-the-less) it is very difficult to acquire a token, if not impossible. Libraries such as this, and command line tools, are not very good at interacting with websites and browsers in the manner your OAuth2 setup require.

I can imagine two solutions.

1. Allow the "password" grant_type which facilitates a more straight forward login behavior (without interacting with a browser and your website)
2. Allow the user to create long-term API tokens on your website. These can be proper OAuth2 tokens that never expire. The user can then copy these and supply them to node-botvac and similar tools.

PS. Did you disable the old login behavior yesterday?

[ostinelli]

@wronex we follow OAuth2 security recommendations, and these include enforcing https for obvious reasons. Re the password grant type:

The Password grant is used when the application exchanges the user’s username and password for an access token. This is exactly the thing OAuth was created to prevent in the first place, so you should never allow third-party apps to use this grant.

(oauth source)

Thank you for the suggestion of allowing users to create long term tokens, this would allow a good compromise between integration needs and users' security. Will discuss internally and get back to you.

[Eisbaeeer]

Very interesting. Is the OAuth2 also usable with the "Vorwerk VR200"? Sinderly Eisbaeeer

[Pmant]

@ostinelli any news on this? A lot of APIs give users the ability to obtain per-app tokens, often as "key" and "secret". Since this library is not used for web services (at least none that I know of) but for local network usage (e.g. ioBroker installations) there is no reachable ssl-endpoint available. Even if that were the case, every user would need to create a dev-account and register his own app. I wonder if OAuth2 has a feature to handle this situation or if this needs to be solved apart from OAuth2.

However, I will update this library as soon as there is a way for users to create app-tokens.

[Eisbaeeer]

Perhaps we can use the existing oauth2 server of iobroker (used for the cloud thing) for that? But then every user of the adapter must also use the cloud service. I don't know if this is user friendly?

[Pmant]

Perhaps we can use the existing oauth2 server of iobroker (used for the cloud thing) for that? But then every user of the adapter must also use the cloud service. I don't know if this is user friendly?

Also that would only be a solution for this single usage scenario (iobroker + cloud adapter), which is only one project using this library. There should be a more common solution for that.

One could argue we could just leave it as is with username / password, because everything is just locally stored. But I think it's never a good idea to force people to enter there credentials anywhere else.

[jbtibor]

I've created pull request to add support for OAuth access token. OAuth authorization is not added, I'm using it in an Alexa skill where OAuth authorization is done within Alexa app or website and token is passed as parameter to the skill. https://github.com/Pmant/node-botvac/pull/12