tidepool-org / user-api Goto Github PK

Allow us to generate tokens for backend use that don't expire and can be stored in configuration data.

If the token is not properly specified, the jwt toolkit throws and it isn't handled by user-api.

The user API has a weak notion of sessions.

Ben has adapted a session management system that can probably work for us. It uses a redis backing store for fast session lookup, and he's done some work on making the adaptations needed to run under our server structure. Ben, please add a reference to it as I can't seem to find it right now.

Our current set of tests require an instance of mongodb; either a local test or one on an accessible server. Proper tests shouldn't require a networked system. Build a mock mongodb that has the minimum set of appropriate functionality to run the tests (we don't need a full mongo simulation, just enough to run the tests).

This will also include modifying the setup code and its callers so that the calling process passes in the mongo (or mock) object to the db_mongo setup.

The current auth system is weak; we want to have a full implementation of OAuth2 available.

Integrate oauth2orize so that Tidepool is a compliant OAuth2 provider.

It would help collaboration if it was super easy to get this running, at least for demonstration purposes, on localhost after first checking out the repo. I need to run this on localhost to integrate my pull request on jellyfish, but I don't know how to provide API_SECRET and some other required variables.

The user API has an unchanging user ID, and allows the end user to edit the email addresses and username associated with the account. There should also be a function to regenerate the private hashes.

(This would allow us to recover from a leaked private hash, for example).

The apiary service has the ability to transparently proxy an api so that apiary can act as a debugger. Now that user-api is deployed, we could permit this to work. It should be quite simple to make it try, but it may be a bit more work to clean up the documentation and make each of the examples actually run.

If a user forgets a password, we should be able to generate and email a temporary password. We need an API to say "generate a temp password on the account with this email address, and if it's subsequently used to log in, replace the password and set a 'requires new password' flag.

Currently our API is not throttled. This will hurt us someday.

Immediate problem is that user-creation is not rate-limited. That should simply be throttled to limit the rate at which is can be called by anyone.

But the API should rate-limit calls to individual tokens to some reasonable number -- X calls a minute, for example. This rate limit should probably be visible in a header, so when you make a call, you can tell how many more calls you have before you get rejected.

"Delete everything" is a feature we should support -- but it's also a feature that users often regret using. We should provide a short period of permissible regret -- deleting a user account should move it to a holding area for a few days (7 days is probably about right, but it should be configurable). We can then run periodic purges to actually clean out these accounts.

This task requires not only implementing the move feature, but also providing a purge script.

This is a bit of a nit and a point of style, but right now /logout returns a 401 if the token didn't exist, etc.

Semantically speaking, if the token isn't provided, then the session no longer exists. If the token has expired, the session no longer exists. If /logout just means "session no longer useable", then I think that the endpoint can pretty much just return 201 for everything.

Currently we have no version support in the API, but restify supports a versioning model. We should define and support multiple versions of the API in a request.

If we have a password breach of some sort, we should be able to flag accounts to require that the users must create a new password after login (or force them through the recovery dialog).

The current set of tests is broad rather than deep. Each API call is tested in basic form and again with total garbage, but there are a lot of untested edge cases. Write more unit tests to more fully exercise the API.

Travis-CI is a continuous integration test system that runs tests on checkin and generates reports. Set it up so that tests are run and the results badge is put up on the repository.

Right now, the username and emails are validated for uniqueness in our database when they are created, but NOT checked again whenever they change. This needs to be fixed.

We currently assume both the input and the output are JSON, but we don't actually negotiate content types or enforce them. We should.

There was a TODO in lib/userapi.js on the createUser() function.

It read

// TODO: add owned accounts

I have deleted it, I do not know what it means, so I am filing this issue so that someone does it at some point.

Coveralls is a tool that works with Travis-CI to run tests and measure how much of the code is tested. Set things up so that our code coverage is automatically tested and reported.

For documentation purposes, a small, well-documented sample application that runs in client-side javascript and demonstrates use of the user API (and possibly the metadata API) would be very useful.

It would be nice to support 2-factor authentication for the user API someday. This will require planning and signing up with an SMS service to send text messages, plus no small amount of code to manage the authentication state.

The current set of tests is slightly split between integration and unit tests. We could use integration tests that check that the API is functional from the point of view of an external client. Write some integration tests that can exercise the API from an external endpoint to make sure that it's functioning as intended in the deployed form. This is most likely making a copy of the test_user_api_unit tests and removing the stuff that is intended to run behind the firewall.

I need an endpoint to verify that a token is valid and who it is. I can imagine this as something like

GET /token/:token

And a response like

404 Not Found

If the token is invalid, or

200
{ userId: abcd, otherPropertiesIfAny: '', ... }

This endpoint should probably be protected by requiring a server-side token

Right now any client can talk to us, and we have no way of distinguishing between clients, which means that a badly-behaved client can't be cut off. We need a system for generating and assigning API keys that are used to establish the initial session.

Initially, client developers can apply to us for keys. Eventually we will want a self-service model.