Feature: Generate User Tokens

[benloh]

Use the "Advanced Panel" to generate User Tokens.

• Only works in admin mode
• The tokens can be made "Shareable" so that a single user token can be used across different graphs, e.g. if a student group is working on multiple graphs, the shareable token can be used for any graph. See Feature: Shared Tokens #241

---

Wiki

Advanced Panel

How protections work

To make it security protections less obvious (and more difficult for students to suss out) there are three levels of password protection.

CAVEAT: This is low grade security at best and is relatively easy to work around.

1. Student / Regular User View

By default, the "Advanced" panel is visible, but only the "Export" tab is visible.

At the bottom of the "Advanced" panel is an unlabeled password input field with no "Submit" button.

• If adminPassword has not been defined however, a ❄︎ will be displayed.

2. Privileged Import User

For some projects, e.g. research groups, sometimes you need to allow a logged in user to be able to import node/edge data. There is a template setting that allows this:

allowLoggedInUserToImport = true

If this is set and a user is logged in, the "Import Data" panel will be visible.

3. Teacher

With a password, a teacher can access teacher-enabled advanced panel tabs:

• Template -- import/export
• Import/Export -- nodes and edges
• User Tokens

In order to access those items, a teacher must enter a password.

• There is no "Submit" button so the password is accepted as soon as the correct phrase is entered.
• The phrase is defined in the project template's adminPassword field.
• Each project can have its own password field, or of course, you can share it across instances.
• If adminPassword has not been defined however, a ❄︎ will be displayed.
• Once the correct password has been entered, the input field will turn into a button "Admin Logout". Clicking that will re-enable the password input field. The password will remain active until you reload or click "Admin Logout"

4. Researcher: Look Up Password

If a teacher forgets the password, or a researcher needs to access the "Advanced" panel, what can they do?

We are disabling the ?admin=true override, so you will have to look up the password via the template.

Digital Ocean
On Digital Ocean, the fix is to look up the current template via ssh.

1. In web console, type NC_CONFIG to determine the dataset name.
2. SSH to Digital Ocean and look up the template:

   ssh <digitalocean>
   cd nc-multiplex/netcreate-itest/runtime
   cat <dataset>.template.toml
   

Turbo360
On Turbo360, the fix is to look up the current template in Turbo360's portal.

1. Go to https://portal.turbo360.co/ and log in
2. Find the relevant project and click "Manage"
3. Click on the "Site" sidebar
4. Click on the "Storage" tab
5. Click on the <dataset>.template.toml file to download it
6. Open the file and look for the adminPassword field.

User Tokens

Historically, user tokens were defined either by using the web console ncMakeTokens command or to use nc-multiplex's UI tool.

The new "Advanced" panel can now be used to generate tokens.

salt

By default, tokens are project-template-specific. The project has a salt string that is used to create a unique hash for the user token.

• salt can be any string less than 12 characters.
• Best practice is to define a salt for every project that needs a unique token.
• If you want to create tokens that can be used across multiple projects, e.g. tokens that can be used across all the projects in a classroom, just use the same salt for each classroom's project.
• If salt is not defined in the template, tokens can still be generated, but the tokens can then be used on any other project that does not have salt defined. (Under the hood, the hash uses just the classId and the projId as the salt, skipping the project salt).
  • If salt is not defined, the "Shareable" tokens checkbox will be automatically checked and disabled, and a warning message displayed.
    

[benloh]

@jdanish Please give this a spin to see if this works for managing user tokens. There are multiple things to try:

1. git checkout dev-bl/user-token
2. npm run dev -- or of course, use ./nc.js --dataset=xxx
3. If necessary, in the console, type NC_CONFIG to determine your currently active template file.
4. Check on these settings:

salt = "exp626"
adminPassword = "danishpowers"
allowLoggedInUserToImport = true

Most likely you won't have salt and adminPassword defined yet. That's fine we want to start there.

Test 1: Check if allowLoggedInUserToImport works

1. Check the allowLoggedInUserToImport value in the template.
2. Go to the Advanced Panel.
3. If allowLoggedInUserToImport = true, the panel should look like this:
   
4. Change allowLoggedInUserToImport to false, and restart the server. The "Import Data" panel should be gone.

Test 2: Check if adminPassword works

?admin=true in the URL should no longer do anything. (Technically we haven't disabled it yet, but the functionality associated with it is no longer there.

1. Assuming adminPassword has not been defined, when you go to the Advanced Panel, you should see a snowflake ("frozen") at the bottom of the screen.
   
2. Change adminPassword to a string of your choosing, restart the server, and a blank unlabeled password field should appear.
   
   Type in the password you stored and the full Advanced Panel should appear: with "Template, Import/Export, User Tokens" available.

One question here is whether this semi-hidden approach is adequate.

Test 3: Check if salt works

1. Assuming salt has not been defined, you should see a warning about salt not being defined:
   
2. Generate a token and make sure that it works. Note the token.
3. Quit the server, start it up with a different graph, also without salt. Try the token. It should work. An undefined salt behaves as a shareable token.
4. Edit the project template, add some kind of salt string.
5. Go to the Advanced Panel and the salt warning should not be there. NOTE: I left the checkbox for shareability, but put it as an advanced option. I can remove it altogether if you think that's better. But I thought this would be a useful reminder/warning of the lack of a salt definition.
6. Generate a token. Make sure it works. Note the token.
7. Quit and start another graph. Try the token -- it should not work.

So please test the various scenarios:

• Researcher administering things on DO
• Teacher administering things on DO

I need to do a round of testing on the initial setup for Turbo360, but wanted to make sure this overall approach makes sense first. If so, then I'll implement some templates on Turbo360 and we can try the workflows there.

[jdanish]

Issue: the tokens I generated work, but the shared ones don't even work in the initial graph ... thoughts? (treat as incorrect password)

Edit: updated screen cap

@benloh wanted to make sure you didn't miss this one.

[jdanish]

I need to run past Kalani, but I think this approach works. We will want to change the word "salt" maybe to make it more intuitive and maybe put "Admin password: " before the box to avoid confusion? Also, is the password checked on the server or client? That is, could I figure out the password easily using the javascript console? It's not terribly likely, but ...

Otherwise, yes I like this approach so far. Note, I've only tested locally so far ... DO soon.

[benloh]

Hmm...maybe we do need to drop the notion of shareable tokens after all. I think the degree of shareability is affected by the presence or absence of the salt value. And there is no easy to way to determine that. Let me revisit that.

---

salt is easily changed to another term. Note that the term only shows up in the UI f you didn't define it in the template. Of course you still have to set it in the template. Other ideas:

• secretKey
• randomKey
• secretToken
• securityToken

i think the important thing at this stage is making sure the admin password approach makes sense. I was deliberately trying to make it vague so that there isn't a giant "Admin Password" field that simply invites hacking. But if that's what you prefer we can do that. Keep in mind that a student going to the Advanced panel will immediately see the "Admin password" field.

The password is definitely not super secure. But you shouldn't be able to see in in plain javascript. If we inadvertently left the project template definition visible then yes it is visible (e.g. if we had a console command like NC_CONFIG that dumps the whole project template data object.

I was trying to avoid the SESAME file approach because that was an nc-multiplex feature that relied on the fact that we had low level access to the file system via the node express server. netcreate-itest doesn't quite have that and we would have to build that in for both DO and Turbo360 as a whole new subsystem. I think if we want a higher level of security, we would want to implement the full authentication system, and although we made some progress with that, a proper implementation is pretty significant and far from completion.

[jdanish]

OK, let's go with secretKey, and use this for now and assume long-term we need full authentication, but this is pretty safe. I'm OK with kids seeing Admin password since they won't have a way to figure out what it is, and honestly none are trying so far. One will eventually, but then it's up to the teacher to hide the sticky-note.