Handle Robots

[mcwhittemore]

Once postfix lands we need to answer how robots can start adding items to a task.

How to add an item via the API is defined here.

The problem that is left, is how to authenticate a robot since only authenticated users can create or edit tasks and items.

My thought is that any user who can make an item should be able to create a robot to create an item.

POST /tasks/:task/robots would be an endpoint authenticated OSM users call that will respond with { robot_token: 'random-string' }. This robot_token would then be a valid way to authenticate for the PUT item endpoint.

The reason I have robots only being able to write to a single task is to provide the ability for to-fix to later limit who can create team-only tasks without having to worry about how this would effect robots. This also seems to imply that an automated process that creates task items should be designed to only create items for one task. I think this is a good convention, but I'm not sure if this is how current generation of task items works.

To do this we'd need a task_robots table. This table would track the task, the user who made the robot, and the token.

We'd also need to change the authentication lib to know about this new authentication mechanism.

cc @batpad @coxchapman @samanpwbb

[batpad]

Based on discussion with @emilymdubois, we're going to try and avoid having multiple ways of authentication -- i.e. either tokens OR OSM credentials.

The way this would work is:

• User logs into OSM on the frontend, and is forwarded to a callback URL on the server.
• The server stores the users osm tokens and username in a Users table in the database.
• The server generates a default token for the user and sends that to the user, that is used to authenticate subsequent requests.
• Users can additionally generate tokens that are scoped to particular projects.

Tokens will be stored in a UserTokens table or so.

Roughly, the work involved here:

• Create a route for oauth_callback that receives the callback from OSM after the user successfully logs in, with an oauthToken and oauthSecret and handles generating a default token and sending that to the user.
• A piece of middleware to validate tokens from the user that looks up the database and checks if the token is valid and what user it belongs to.
• An end-point that allows a user to request a new token, optionally scoped to project
• An end-point that allows a user to delete / invalidate a token (can be punted on for now)

[batpad]

So just an update here:

The work to generate tokens based on OSM auth is almost done here: https://github.com/osmlab/to-fix-backend/pull/138

We did change around a bit how we do it, deviating from what is outlined in the above comment. We are not using the database to store any of the user info right now - we just encode the user info payload into a JWT token that can be decoded by the backend to validate the user info.

The client then sends the jwt token it receives after logging into OSM with every request -- middleware will then handle decoding the jwt token and passing the user info to end-points which can decide if the user is valid or not.

For now, we will define a list of trusted users at the application level and punt on more fine-grained permissions, which can be added later.

[batpad]

Making notes of things to do before we can close out auth:

• Cleanup tests for older auth work-flow (don't need the mocks any more)
• At least outline the methodology for how we will test this, even if we are unable to implement that right now.

[batpad]

This is done! We generate tokens based on OSM Auth and those tokens can be used to authenticate on the API.