416 user api

[jum-s]

this PR

• create a user model, reusing db api
• create a user db independent from things
• implement couchdb views for users
• implement a findOrCreate user model method as a promise
• create routes for userInfo access (by _id)

Questions in the air/ To discuss

• one user document per provider seems the most simple way to treat a user on the platform, unifying every providers under a single user doc would introduce unnecessary complexity
• shall user db be public access aka do user routes need some sort of authentication?
• data validation seems light, but since only external providers post to the database it looks enough to me, is it to you?

[jum-s]

So far, User record are immutable because it only stores ID provider references. It strictly implements OCP, and KISS

Now, if contact information on the provider server are updated, how does data.tranformap.io keep user store updated, since the user store db has no versioning? User store provides a provider URL. To be a URI you could append the username, and gets another way to cantact the user An update endpoint would open a whole new architecture (with all CRUD options). I do not quite understand the necessity of this agreedTos storage while it could be implicit, with a 'less data storing' solution. When a new user signs up, they are sent to the provider page agreement, and findOrCreateUser as already implemented Then, if a new user is created, they are redirected to TOS with an 'Agree' button. If the user clicks on agree, then it would continue/next This is an implicit agreement that keeps all the logic in the User model creation.

[jum-s]

A quick look at what user stories look like :

As a new user, when i click on Sign up it creates a user store and ties it to the ID provider and redirects to TOS when i click on Agree TOS button it redirect to the editor

As a new user, when i click on disagree TOS button it deletes the user, and detroys the session and redirects to /

As an already authenticated user, when i click on the editor button, it automatically sign in and redirect to the editor

As an already authenticated user, when i click on the logout button, it destroys the session and redirect me to /

As a logged in user that wants to login with another identity, when i go the ID provider setting and untie/remove ID provider link to data.transformap.co when I click on the sign in button it redirects to provider authentcation page

[acorbi]

@jum-s

A quick look at what user stories look like :

Can you please link me to the place where can I find these?

I do not quite understand the necessity of this agreedTos storage while it could be implicit, with a 'less data storing' solution. When a new user signs up, they are sent to the provider page agreement Then, if a new user is created, they are redirected to TOS with an 'Agree' button.

The alternative you are proposing here sounds good to me. Where I cannot connect the dots though is on the user creation / signup part. https://tree.taiga.io/project/transformap/task/415 and https://tree.taiga.io/project/transformap/task/427 only mention Authentication (login) not user creation. So....

Where are users being created? I haven't thought much about this yet, but let me think aloud here... Since we currently use gitlab as "authentication method", users would need to have an account there (in our case, the provider is lab.allmende.io). The missing piece (for me, at this point) is then a "registration/signup" UI which lets the user register on lab.allmende.io and (as you propose) accept the TOS. Then they would be properly registered users and authorized to make changes and the only thing they need to do in the editor is login, which we already have.

Summary: I'm happy with scratching the agreedTos and showTosMessage parts of my implementation but still I'm unclear about user creation / signup.

maybe something @almereyda can shed some light on?

[jum-s]

@acorbi User already has a table which stores provider information in order to have a session. The user stories are here to give idea of how it should work seamlessly. It's not integrated yet (you can check that /auth path already redirect to provide rinformation. That's the only feature fully implemented so far because completly independant from the editor. Then the login button redirect to this URL.

[acorbi]

@jum-s

So far, User record are immutable because it only stores ID provider references. User already has a table which stores provider information in order to have a session.

Understood, BUT how do the records on this user table get created? Am I overseeing something or there is currently no concept/plan for user sign-up?

In my understanding we just have a concept/plan for the login, not for user creation. So, how about the following:

• I put 1-2 hours coding and add a sign-up button to the editor (close to the login button) which then lets users create an account after agreeing the TOS (which could then be embedded in a scrollable textarea) specifying username and email and POSTing them to user endpoint.

• I remove the agreedTos and showTosMessage parts of my implementation

@almereyda what do you think?

[jum-s]

It was reported multiple times including here & here that a user store get created when login for first time. It is store on a User database which stores an object that looks like this fixture.

To me, a resource server needs to match Id provider data against its own stored data, which garantees the 'rightfulness' of the identity to the editor and maintain a session from pages to pages. Passport integrates all of that seamlessly within one library.