Conceptualise user management UI

[LukSteib]

Goal

Concept on how to handle user management

Context

We want to provide a UI that allows admin users to login, create new users and generate jwt tokens for the newly created users.
Tbd: In general might be nice to include functionality to re-generate and copy+share jwt token (see s1 in asset section)

Assets

s1:

Tasks

• Discuss concept how we want to handle user management
• Create mini mock
• Discuss and iterate

[valiafetisov]

The rough first version of the UI concept:

• Main page to explain the project and lead to documentation
• "User space" – login and generate/revoke tokens
• Existing graphql playground (probably inside the iframe)

Initial mock

There is also an orange version (to match logo)

Outstanding questions

• Would users be able to sign up without any invitation to get read access?
• Do we want to have different types of tokens for read vs write access? I guess this can be done later
• Do we want to display all frontend sessions as "tokens"? Then we also need to add expiry information into the table
• I guess it's better to sign up with emails (to be able to restore password) but for now this can be ignored, since our current approach is login + password auth only

[LukSteib]

I like the general structure presented in the mock.

Do we want to have different types of tokens for read vs write access? I guess this can be done later

If we do this later I assume the default is going to be read only, right? And then we manually grant write access to selected users or how do you think about it

Do we want to display all frontend sessions as "tokens"? Then we also need to add expiry information into the table

Can you elaborate on that point? Not sure whether I can follow your trace of thought here.

[valiafetisov]

If we do this later I assume the default is going to be read only, right?

We don't distinguish this yet, we only have general session tokens. But I think it's helpful functionality and I would suggest to implement that, that's why I put it into the mock. It's only a question of prioritisation.

Do we want to display all frontend sessions as "tokens"? Then we also need to add expiry information into the table

Can you elaborate on that point? Not sure whether I can follow your trace of thought here.

Related to the previous point, the only tokens we have at the moment are the ones you get after you signed in (this will stay same also when we will use UI for sign in). Those tokens are not revocable yet, but it's also important requirement that we should definitely enforce to be able to sign out. Once this is done, the suggestion is to just show it in the same (or maybe a separate) table on the same page, indicating that this is origin-restricted token of the current session.

Updated the mock to reflect that (also, I think orange version fits better to the logo)

[valiafetisov]

One question that popup during unrelated discussion:

• Can graphql playground receive valid auth header as soon as user is logged in?
  • This will let user to use UI to login and will not force them to manually call signIn and copy-paste headers
  • If so, we should probably move login to the header and rename "User Space" to something else

[valiafetisov]

Can graphql playground receive valid auth header as soon as user is logged in?

• It's possible to assign a cookie to anyone signing in via our UI and then authorize them based on a cookie (as a fallback if authentication header is not present)
• It also seems possible to provide request.globalHeaders to the graphql middleware (depending on the user) which will magically add this info to every request (but this doesn't seem to help, since we would still need a cookie to identify user to set their globalHeaders)

So in any case, it's possible to improve overall UX and allow users to not explicitly set headers in the playground if they are already logged in the UI. Based on this, I will rename User Space to API token generation and place username in the header, so it's also visible on the playground page