Feature: Graph-Specific Token Generator

[benloh]

Request: Ideally, connect token creation to a specific database, so that students who have access to tacitus can’t edit indiana and vice versa Ideally they can’t even see it, but can’t edit is good enough for now

[benloh]

Features

• Tokens are generated for a specific graph only. They cannot be used with other graphs.
• Graphs are not viewable unless you are logged in.
• Tokens are NOT represented in the URL so that graph URLs can be easily copied and shared.

Design Issues

1. Individual Graph Management
   If tokens are generated separately for each graph, then each graph needs its own management page where tokens can be generated (and stored?)

2. Main Page Design
   If you need to login before seeing a graph, we need to hide (or not render) the graph until the user is logged in.

3. Public Access
   If you want to make a graph publicly visible, you need to be able to bypass the authentication.

4. Integrate Single Sign-On? oauth? auth0?
   Probably not because we would need to store usernames and passwords?

---

Design Spec

ROUGH DRAFT

General

• Update template file without restarting server
• Document default template.

Public

• Private graph viewable only on login
• Private flag set via template

Admin

Login

• Password defined via file
• Single password for site
• Password form for admin page

Permissions

• Stop a database

• Create new database -- Only admins can create a new database.

• Handle new database request via direct URL -- Don't create a new database if the graph is not running.

• Periodic ping to make sure server is still running -- Contact admin if disconnected.

• home.html arbitrary page. Fallback to defaulthome.html?

[benloh]

Addresses #72.

[benloh]

@jdanish A few design questions about token management and graph management in general.

There are two competing design directions here: one is an open bottom-up design that encourages the easy creation and maintenance of graphs, and another is a more restricted top-down approach that limits access to graphs.

Given what you've described in your requirements, I think you'd like the more restricted version.

There are a few key questions:

• Who can create graphs?
• Who can start/stop graphs?
• Who can add/edit templates?
• Who can Generate Tokens?

The simple solution is to basically have three levels of users: an admin user, a general graph user, and a public user.

1. The public user can view any graph designated as public.
2. The general graph user can only access graphs for which they have a login token.
3. The admin user is the only one who can create a new graph, start/stop graphs, add/edit templates, and generate tokens.

I imagine we're looking for some balance between being "secure-enough" and "easy to maintain". It'd be nice to keep things simple. I'd rather not have to implement a whole database for managing usernames and passwords as that seems like overkill.

Proposed Approach

So here's a proposed approach. Please let me know what you think.

1. Public Access
   Since you want graphs to be hidden unless you are logged in, we can hide the graph until the user enters their token.
   If you want to be able to have public graphs, though, we probably need to be able to set a flag somewhere that allows users to view the graph without logging in. This is probably a future feature.

2. General Graph User
   This would work essentially the same way it currently does. You enter a token to be able edit a graph. Tokens are specific to a graph, so you can't arbitrarily use your token to view/edit any graph.

3. Admin User
   The admin user is the complex case. There are a few considerations:

URL

The main NetCreate Multiplex site will be accessible via a special URL, e.g. http://nc.com/manage or http://localhost/manage. We can use manage, or admin or whatever you prefer.

One question here is what should the root / page display? For now we'll just throw up the logo and contact info.

Password Entry

Assuming url obscurity is not enough, we can add a password. There are a few ways we could do it.

• Password via Parameter -- One easy solution would be to use the MEME approach of adding a ?danishpowers parameter. This way you can cut and paste the URL and quickly log in. The problem is that it would expose the password if you are projecting on a screen. And practically speaking, it's really no different than using an obscure URL.

• Password Field -- A password field is more difficult to implement and more annoying from a UI perspective. Every time you want to visit the Multiplex page, you'd have to enter the password. If we wanted to remember your logged in status, we'd have to implement a separate session manager. But this is a little more secure.

So right now I'm inclined to implement something like this:

1. When you go to /admin you'll see nothing but a password field.
2. You enter the password, e.g. kalanipowers
3. The Multiplex page displays.
4. You can add, stop, generate tokens, etc.
5. If you navigate away and come back you have to enter a password again.

Your password is basically good as long as your window is open. This is simple and would not require a session manager and we won't have to worry about logging out, etc.

Password Setting

Finally there is the issue of how to set the password. You probably don't want a single password that is used across all of your installations.

One idea is to use a local file override. For example, when the app starts up, it looks for a file named SESAME in the root folder. If it's there, it uses the text in file as the password. If it doesn't file the file, it defaults to a common password, e.g. kalanipowers.

Alternatively, we could have you modify the code directly, but that seems a little less user-friendly. Adding/changing a SESAME file seems like something anyone with tech skills can do.

This is obviously only very low grade security though and anyone who's determined can get in. But perhaps this is good enough?

If we wanted to go all out, we could set up a database of usernames and passwords and grant different permissions to different users, but that would make the system much more difficult to use and maintain let alone cost a lot more to develop.

Thoughts?

[kalanicraig]

Hi! Joshua and I have been talking about these so we have some answers. TL;DR: public access is the only place where we probably need to chat. Public Access: Here’s where my use cases and Joshua’s diverge fairly considerably, but we have potential projects and long-term goals in both arenas. My user base will want to be able to show their graphs on a live server without having to package and upload elsewhere. Joshua needs private graphs that only allow viewing to authorized users. What would we be talking about, in cost and time considerations, to have a flag in each graph's template that says “private” or “public” and needs to be set in that template prior to server start? Public graphs would operate as they currently do where you need to login to edit only. Private would work as you suggested where you need to login to see the graph, nodes, etc. If you change your mind about a graph’s public/private nature, you’d need to stop and restart the server after changing the template as an admin user, but that’d be flexible enough to work for both our audiences without you having to put in a public/private button on the admin page. General Graph User: We are all on the same page. A set of tokens only works for that specific graph. Admin User: We are on the same page with most of this, but more detail here just to make sure we’re explicit. What you’ve described—a separate file with that install’s password, and a default backup that’s built into the system—is good enough for now. We want the NEH to pay for anything fancier. The default should not be kalanipower, probably, although that does make me feel like a superhero. A session-only admin password is fine. That’s how the tokens work now, unless you use the right URL, so we know the model works. Admin rights are required to stop a database Admin rights are required to create a new database Because admins will be the only folks who can create or stop a DB, we don’t need auto kill (and we wouldn’t want auto-kill after 24 hours because we’ll now be leaving these up for weeks at a time depending on the activity). Ideally, a NetCreate app left open would ping periodically, and if the graph was killed it will require a reload before anything else can happen, similar to Meme (so it might report connection issues until the graph is re-started). This might include a message that says to contact your admin / instructor. Note that undergrads with bad network connections might have this happen and still need to look at things, so this should be a non-modal alert, unlike the meme approach if that is possible. Root page: I’ll play with this and send something, but logo and contact info is great for now. Can we load a “homepage.html” file that’s somewhere in the build folder, like we’re doing with the root password, to make this more flexible for other installs too?

…

On Jul 25, 2020, at 8:15 PM, benloh ***@***.***> wrote: @jdanish <https://github.com/jdanish> A few design questions about token management and graph management in general. There are two competing design directions here: one is an open bottom-up design that encourages the easy creation and maintenance of graphs, and another is a more restricted top-down approach that limits access to graphs. Given what you've described in your requirements, I think you'd like the more restricted version. There are a few key questions: Who can create graphs? Who can start/stop graphs? Who can add/edit templates? Who can Generate Tokens? The simple solution is to basically have three levels of users: an admin user, a general graph user, and a public user. The public user can view any graph designated as public. The general graph user can only access graphs for which they have a login token. The admin user is the only one who can create a new graph, start/stop graphs, add/edit templates, and generate tokens. I imagine we're looking for some balance between being "secure-enough" and "easy to maintain". It'd be nice to keep things simple. I'd rather not have to implement a whole database for managing usernames and passwords as that seems like overkill. Proposed Approach So here's a proposed approach. Please let me know what you think. Public Access Since you want graphs to be hidden unless you are logged in, we can hide the graph until the user enters their token. If you want to be able to have public graphs, though, we probably need to be able to set a flag somewhere that allows users to view the graph without logging in. This is probably a future feature. General Graph User This would work essentially the same way it currently does. You enter a token to be able edit a graph. Tokens are specific to a graph, so you can't arbitrarily use your token to view/edit any graph. Admin User The admin user is the complex case. There are a few considerations: URL The main NetCreate Multiplex site will be accessible via a special URL, e.g. http://nc.com/manage or http://localhost/manage. We can use manage, or admin or whatever you prefer. One question here is what should the root / page display? For now we'll just throw up the logo and contact info. Password Entry Assuming url obscurity is not enough, we can add a password. There are a few ways we could do it. Password via Parameter -- One easy solution would be to use the MEME approach of adding a ?danishpowers parameter. This way you can cut and paste the URL and quickly log in. The problem is that it would expose the password if you are projecting on a screen. And practically speaking, it's really no different than using an obscure URL. Password Field -- A password field is more difficult to implement and more annoying from a UI perspective. Every time you want to visit the Multiplex page, you'd have to enter the password. If we wanted to remember your logged in status, we'd have to implement a separate session manager. But this is a little more secure. So right now I'm inclined to implement something like this: When you go to /admin you'll see nothing but a password field. You enter the password, e.g. kalanipowers The Multiplex page displays. You can add, stop, generate tokens, etc. If you navigate away and come back you have to enter a password again. Your password is basically good as long as your window is open. This is simple and would not require a session manager and we won't have to worry about logging out, etc. Password Setting Finally there is the issue of how to set the password. You probably don't want a single password that is used across all of your installations. One idea is to use a local file override. For example, when the app starts up, it looks for a file named SESAME in the root folder. If it's there, it uses the text in file as the password. If it doesn't file the file, it defaults to a common password, e.g. kalanipowers. Alternatively, we could have you modify the code directly, but that seems a little less user-friendly. Adding/changing a SESAME file seems like something anyone with tech skills can do. This is obviously only very low grade security though and anyone who's determined can get in. But perhaps this is good enough? If we wanted to go all out, we could set up a database of usernames and passwords and grant different permissions to different users, but that would make the system much more difficult to use and maintain let alone cost a lot more to develop. Thoughts? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKL4NHUWIHADGBDSMSUTRTR5NYTVANCNFSM4PHHP2XQ>.

[kalanicraig]

I should clarify: my users will need to show their graphs on a live server to *audiences who will only consume, not edit, the graphs* (so much as the graph appears now prior to inputting an access token). Also, Joshua says I should still get credit in the password but kalanipower feels very Prince of Greyskull.

…

On Jul 25, 2020, at 9:04 PM, Kalani Craig ***@***.***> wrote: Hi! Joshua and I have been talking about these so we have some answers. TL;DR: public access is the only place where we probably need to chat. Public Access: Here’s where my use cases and Joshua’s diverge fairly considerably, but we have potential projects and long-term goals in both arenas. My user base will want to be able to show their graphs on a live server without having to package and upload elsewhere. Joshua needs private graphs that only allow viewing to authorized users. What would we be talking about, in cost and time considerations, to have a flag in each graph's template that says “private” or “public” and needs to be set in that template prior to server start? Public graphs would operate as they currently do where you need to login to edit only. Private would work as you suggested where you need to login to see the graph, nodes, etc. If you change your mind about a graph’s public/private nature, you’d need to stop and restart the server after changing the template as an admin user, but that’d be flexible enough to work for both our audiences without you having to put in a public/private button on the admin page. General Graph User: We are all on the same page. A set of tokens only works for that specific graph. Admin User: We are on the same page with most of this, but more detail here just to make sure we’re explicit. What you’ve described—a separate file with that install’s password, and a default backup that’s built into the system—is good enough for now. We want the NEH to pay for anything fancier. The default should not be kalanipower, probably, although that does make me feel like a superhero. A session-only admin password is fine. That’s how the tokens work now, unless you use the right URL, so we know the model works. Admin rights are required to stop a database Admin rights are required to create a new database Because admins will be the only folks who can create or stop a DB, we don’t need auto kill (and we wouldn’t want auto-kill after 24 hours because we’ll now be leaving these up for weeks at a time depending on the activity). Ideally, a NetCreate app left open would ping periodically, and if the graph was killed it will require a reload before anything else can happen, similar to Meme (so it might report connection issues until the graph is re-started). This might include a message that says to contact your admin / instructor. Note that undergrads with bad network connections might have this happen and still need to look at things, so this should be a non-modal alert, unlike the meme approach if that is possible. Root page: I’ll play with this and send something, but logo and contact info is great for now. Can we load a “homepage.html” file that’s somewhere in the build folder, like we’re doing with the root password, to make this more flexible for other installs too? > On Jul 25, 2020, at 8:15 PM, benloh ***@***.*** ***@***.***>> wrote: > > > @jdanish <https://github.com/jdanish> A few design questions about token management and graph management in general. > > There are two competing design directions here: one is an open bottom-up design that encourages the easy creation and maintenance of graphs, and another is a more restricted top-down approach that limits access to graphs. > > Given what you've described in your requirements, I think you'd like the more restricted version. > > There are a few key questions: > > Who can create graphs? > Who can start/stop graphs? > Who can add/edit templates? > Who can Generate Tokens? > The simple solution is to basically have three levels of users: an admin user, a general graph user, and a public user. > > The public user can view any graph designated as public. > The general graph user can only access graphs for which they have a login token. > The admin user is the only one who can create a new graph, start/stop graphs, add/edit templates, and generate tokens. > I imagine we're looking for some balance between being "secure-enough" and "easy to maintain". It'd be nice to keep things simple. I'd rather not have to implement a whole database for managing usernames and passwords as that seems like overkill. > > Proposed Approach > > So here's a proposed approach. Please let me know what you think. > > Public Access > Since you want graphs to be hidden unless you are logged in, we can hide the graph until the user enters their token. > If you want to be able to have public graphs, though, we probably need to be able to set a flag somewhere that allows users to view the graph without logging in. This is probably a future feature. > > General Graph User > This would work essentially the same way it currently does. You enter a token to be able edit a graph. Tokens are specific to a graph, so you can't arbitrarily use your token to view/edit any graph. > > Admin User > The admin user is the complex case. There are a few considerations: > > URL > > The main NetCreate Multiplex site will be accessible via a special URL, e.g. http://nc.com/manage <http://nc.com/manage> or http://localhost/manage <http://localhost/manage>. We can use manage, or admin or whatever you prefer. > > One question here is what should the root / page display? For now we'll just throw up the logo and contact info. > > Password Entry > > Assuming url obscurity is not enough, we can add a password. There are a few ways we could do it. > > Password via Parameter -- One easy solution would be to use the MEME approach of adding a ?danishpowers parameter. This way you can cut and paste the URL and quickly log in. The problem is that it would expose the password if you are projecting on a screen. And practically speaking, it's really no different than using an obscure URL. > > Password Field -- A password field is more difficult to implement and more annoying from a UI perspective. Every time you want to visit the Multiplex page, you'd have to enter the password. If we wanted to remember your logged in status, we'd have to implement a separate session manager. But this is a little more secure. > > So right now I'm inclined to implement something like this: > > When you go to /admin you'll see nothing but a password field. > You enter the password, e.g. kalanipowers > The Multiplex page displays. > You can add, stop, generate tokens, etc. > If you navigate away and come back you have to enter a password again. > Your password is basically good as long as your window is open. This is simple and would not require a session manager and we won't have to worry about logging out, etc. > > Password Setting > > Finally there is the issue of how to set the password. You probably don't want a single password that is used across all of your installations. > > One idea is to use a local file override. For example, when the app starts up, it looks for a file named SESAME in the root folder. If it's there, it uses the text in file as the password. If it doesn't file the file, it defaults to a common password, e.g. kalanipowers. > > Alternatively, we could have you modify the code directly, but that seems a little less user-friendly. Adding/changing a SESAME file seems like something anyone with tech skills can do. > > This is obviously only very low grade security though and anyone who's determined can get in. But perhaps this is good enough? > > If we wanted to go all out, we could set up a database of usernames and passwords and grant different permissions to different users, but that would make the system much more difficult to use and maintain let alone cost a lot more to develop. > > Thoughts? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKL4NHUWIHADGBDSMSUTRTR5NYTVANCNFSM4PHHP2XQ>. >

[benloh]

Thanks for the feedback! I hope to get this for you this week.

How about 'kpop` as a password then? :)

[kalanicraig]

So we’re associating me with a group of people who weaponized their hashtag to support black lives matter? I am 100% behind this as a solution. Also: I have the power! *ahem* Thanks!!!

…

On Jul 27, 2020, at 2:38 PM, benloh ***@***.***> wrote: Thanks for the feedback! I hope to get this for you this week. How about 'kpop` as a password then? :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACKL4NBMJH26MHG75JEYEF3R5XCQRANCNFSM4PHHP2XQ>.

[jdanish]

Awesome. If you think we will bust the budget with our tweaks / feedback let us know. Thanks!

[benloh]

We have about 20 hours left. If I do a bare bones version of this, I might still be able to do a simple filtering solution. But it's also possible filtering would need to be dropped. Is that OK?

I also want to make sure we reserve time to deal with bugs. I've run a 3-4 person test, but it'd be great if you could get your labs to bang on it together at the same time.

[jdanish]

Yes, if we can’t get filtering now, that is OK. We can definitely help with testing once it is ready. Just let us know when! Thanks, Joshua

…

---- Joshua A. Danish (he, him, his) (https://www.mypronouns.org/ <https://www.mypronouns.org/>) jdanish@gmail.com http://www.joshuadanish.com

On Jul 27, 2020, at 3:55 PM, benloh ***@***.***> wrote: We have about 20 hours left. If I do a bare bones version of this, I might still be able to do a simple filtering solution. But it's also possible filtering would need to be dropped. Is that OK? I also want to make sure we reserve time to deal with bugs. I've run a 3-4 person test, but it'd be great if you could get your labs to bang on it together at the same time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKGCKV5QQSGXO36JOGH5CLR5XLUZANCNFSM4PHHP2XQ>.

[benloh]

There are definitely a number of things to fix before large scale testing is worth it. I'll let you know by the end of this week. On Mon, Jul 27, 2020 at 1:19 PM Joshua Danish <notifications@github.com> wrote:

…

Yes, if we can’t get filtering now, that is OK. We can definitely help with testing once it is ready. Just let us know when! Thanks, Joshua ---- Joshua A. Danish (he, him, his) (https://www.mypronouns.org/ < https://www.mypronouns.org/>) ***@***.*** http://www.joshuadanish.com > On Jul 27, 2020, at 3:55 PM, benloh ***@***.***> wrote: > > > We have about 20 hours left. If I do a bare bones version of this, I might still be able to do a simple filtering solution. But it's also possible filtering would need to be dropped. Is that OK? > > I also want to make sure we reserve time to deal with bugs. I've run a 3-4 person test, but it'd be great if you could get your labs to bang on it together at the same time. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub < #98 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABKGCKV5QQSGXO36JOGH5CLR5XLUZANCNFSM4PHHP2XQ >. > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKWRMOUH2F7QHZCAMMZZQDR5XOLXANCNFSM4PHHP2XQ> .

[jdanish]

OK, thanks. I need to work on a grant for filtering and sticky notes / comments now ;) Joshua

…

On Jul 27, 2020, at 4:29 PM, benloh ***@***.***> wrote: There are definitely a number of things to fix before large scale testing is worth it. I'll let you know by the end of this week. On Mon, Jul 27, 2020 at 1:19 PM Joshua Danish ***@***.***> wrote: > Yes, if we can’t get filtering now, that is OK. > > We can definitely help with testing once it is ready. Just let us know > when! > > Thanks, > > Joshua > > ---- > Joshua A. Danish (he, him, his) (https://www.mypronouns.org/ < > https://www.mypronouns.org/>) > > ***@***.*** > > http://www.joshuadanish.com > > > > > > > > > On Jul 27, 2020, at 3:55 PM, benloh ***@***.***> wrote: > > > > > > We have about 20 hours left. If I do a bare bones version of this, I > might still be able to do a simple filtering solution. But it's also > possible filtering would need to be dropped. Is that OK? > > > > I also want to make sure we reserve time to deal with bugs. I've run a > 3-4 person test, but it'd be great if you could get your labs to bang on it > together at the same time. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub < > #98 (comment)>, > or unsubscribe < > https://github.com/notifications/unsubscribe-auth/ABKGCKV5QQSGXO36JOGH5CLR5XLUZANCNFSM4PHHP2XQ > >. > > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#98 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAKWRMOUH2F7QHZCAMMZZQDR5XOLXANCNFSM4PHHP2XQ> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#98 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKGCKROE7X437WRZFQLA3TR5XPTRANCNFSM4PHHP2XQ>.