Spec out and build an identity management API (e.g. listing/deleting/etc users) about horizon

[marshall007]

To clarify, I'm saying:

class UserCollection extends Collection {
  current() { /* ... */ }
}

horizon.users = new UserCollection(...)

[deontologician]

@Tryneus @coffeemug is this issue useful for tracking purposes or is it superseded by the work done on the server for auth?

[coffeemug]

This is for tracking purposes and not superseded. The big question is what the user management API will look like (e.g. how do I list users?) and whether we'll have a specialized one or let developers access user tables through the standard fusion API.

[deontologician]

Right now the implementation of authentication has an internal table that tracks users. I guess an outstanding question is whether we should:

• A) move the metadata table to be an app level table
  • pro: only one table, can use existing horizon commands to manage users
  • con: this would be the first table we create for a user. They may mess it up so horizon can't understand it
• B) allow both an internal table for users and an app table for users if the app creator wants one
  • pro: internal table is always understandable by horizon. App table is exactly what the app developer expects, with no magic.
  • con: we lose atomic operations on users, since data is split over two tables for one conceptual entity
• C) ensure users are managed entirely internally by horizon, perhaps adding special commands for modifying a user
  • pro: App developers can't break the user table, we can store whatever internal data we want, and expose only operations that are safe/valid on users.
  • con: maybe inflate the api a bit

I'm partial to C, we might make a user look like a pseudo-collection:

horizon.user(userId).update({foo: 'bar'})

The internal user document would look like:

{ "id": 1,
  // auth/permissions related fields here
  "appData": {
    "foo": "bar"
  }
}

[deontologician]

ping @Tryneus

[deontologician]

Ok, so we've settled on pseudo-tables, roughly as described in #151 . The client is also going to add a .currentUser().fetch() .currentUser().watch() method that looks at the user id in the jwt received in the handshake, and then queries the user table appropriately.

[marshall007]

@deontologician since the users collection is available by default and there are probably going to be additional operations that only apply to the users collection, we could expose it statically:

horizon.users == horizon('users')
horizon.users.current() == horizon('users').get(CURRENT_USER_ID)

I can see this being useful for other terms/helper methods like horizon.users.active().watch() for observing users who are currently "online".

[deontologician]

I think it'd be nice to support the normal table interface on it as well, so we don't have to duplicate things. Are you thinking about both horizon.users and horizon('users') existing?

[marshall007]

@deontologician I certainly think people would expect horizon('users') to work too, but I was thinking horizon.users would be an instance of UserCollection, extended with additional methods like .current(). We'd have to add a special case in the Collection constructor in order for horizon('users') to return the correct instance type.

[deontologician]

Cool, that seems reasonable

[deontologician]

Bug fixed