Cooperative Oterm, part II: Sharing using UUIDs

On the previous instalment we saw how can several browsers access the same terminal, but it requires to log in with the proper user. Here we will discuss how to overcome such limitation, and security implications on the implemented method.

Using Universal Unique IDs.

First of all we should give each terminal instance a unique id into our system, so it does not matter from where you come, you can access to this terminal. It can be an internal identifier, random or not.

Also if we have a truly random, and very difficult to guess ID it can be used as "password" to access the terminal. This requires several things as a trusted network where third parties can not see what you write, and a channel to communicate such id. The first should be solved before using oterm as communication is through HTTPS; if you decide to use HTTP you already are giving out everything. For the passing of UUID user must use their own means, be it an email (encrypted), chat, or shouting out the 36 characters.

So we desire a truly random ID, which can not be guessed easily, which can not collide. So what better than UUIDs. Also linux is very kind and has a truly random UUID generator at /proc/sys/kernel/random/uuid.

Modifing the code

Once we have the idea clear we have to accomplish the changes. First instead of accessing the terminals at /term/[ID] we will access them at /uuid/[UUID], and remove the old interface. We could keep it, but there is no need for it. Then we added a dictionary to map the UUIDs to the process they control.

One very important point is authentication. Now there is no need to authenticate to use the UUID terminals, if you know the UUID, but if you dont know it you must be able to create new terminals. So now the PAM module protects not all the URL tree, but only /term/, as is here where we ask for the status of the sessions and create new terms. If you can not access some information dialog will tell you that you can not, and ask to login.

Also as we had to change a lot around to make this happend we updated the structure to use latest onion developments, and even created new developments to ease the use. So now we use better the url handlers,  opack with support for directory packing, and a little styling up of the presentation.

Also some pool mode bugs were solved, like when a connection timeout, it is removed and also needs to process some data.

How to share the terminal.

So now when user creates a new terminal after loging in, the terminal is accessed using a UUID, and this UUID does not need password to access, as knowledge of the UUID implies that access has been granted.

So if you want to share the terminal, just give the address, maybe changing the server name for the proper IP or domain name.

On next instalment we will see how to share the terminal on the wide internet using UPnP. It will not be coded in, but used externally, and will have minimal integration.