Enhanced User Signup Process

[birm]

What functionality should we support for adding users? @nanli-emory seemed to want to have a conversation about this.

[nanli-emory]

I'm not sure what functionalities we need. But it should involve our system's Authorization&Authentication strategies. what I have in my mind is the workflow.

1. user registration(admin or normal). [We may need to verify the email address]
2. our system sends a notification to the system admins.
3. system admins give permission to a user.
   I think this workflow should work fine. What do you think?

[akhil-rana]

I was thinking of making a visual redesign. I'm not really familiar with the signup process though but I'll try and make the current signup page more user friendly if you'd like. Just redesigning the frontend of the current page which seems a little odd and not consistent with the application throughout.

[mgautam98]

@nanli-emory Would't it takes time if system admins give permission to the user?

[birm]

Yes, that does mean, in effect, the signup page is useless to non-admins as is. However, we've had some back and forth on letting users sign up then be approved by an admin. I can't remember if we liked the idea or not though.

[nanli-emory]

user is a general concept for a system. We need to clarify what type of users you wanna give what kind of permissions (read/write resource). It involves a complicated system design process. For normal users, the registration process should be easy and doesn't need system admins to prove anything (as we sign up an account on social media website). The problem is that we still need to clarify what our system needs are and what direction we could scale.

[mgautam98]

1. We can just give all users Visitor access until they get permission.
2. How does the admin know that person claiming to be is the actual person? Some Id Card no? each organization has.

[birm]

For 1, I think we need a better definition for what visiting is. For one project, visitors were only allowed certain kinds of writes, but that was a one-off. I think we'll end up in a situation where visitors get read-only access to a certain subset of slides. Deciding this is part of it, but sometimes slides are private for legal/privacy/research reasons, so we can't just give full access to everyone.

For 2, I think we have to assume that the admin knows the google id for each person. Though impersonation is a valid thing to consider. Maybe keeping it as admin-driven makes the most sense?

[viditvarshney]

For 1, I think we need a better definition for what visiting is. For one project, visitors were only allowed certain kinds of writes, but that was a one-off. I think we'll end up in a situation where visitors get read-only access to a certain subset of slides. Deciding this is part of it, but sometimes slides are private for legal/privacy/research reasons, so we can't just give full access to everyone.

yeah! in addition to your words, we can do one thing we can make to options public and private for public it is a chamber for all( visitors)
and for the private--> user must have the admin access by which he/she can access the legal/private or research-related slides

By default the user treated as a Public ( visitor) after sign up, the user has access to the legal/private files for the research purposes

[mgautam98]

In that case we have to make it a Invite Only feature where admins can send email with a link having token through which the user can register. What do you think?

[darkCavalier11]

I think jwt is a suitable way to authenticate different users. the admin sends jwt only to the specified user and every time any user trying to access some data server will run a middleware to validate the jwt.

[viditvarshney]

but if admin involves in this process for sending.. then it is time consuming isn't it ? correct me if i am wrong

…

On Sun, Mar 29, 2020, 10:18 PM darkCavalier11 ***@***.***> wrote: I think jwt is a suitable way to authenticate different users. the admin sends jwt only to the specified user and every time any user trying to access some data server will run a middleware to validate the jwt. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#254 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIETYZKXQVYM5GICUADELA3RJ53UDANCNFSM4LULQS6A> .

[darkCavalier11]

Admin involved in a single time sending Auth token to all the peers. The token is updated in the database of the peers. In future if anyone try to access certain admins' work the middleware function in the server validate the token and give access to the person depending on the token.

[Hemansh31]

@birm @nanli-emory is the current implementation of signing up under development?

[birm]

I think that #371 has done a lot for this issue, but I'm leaving it open for additional comments.