Open_registration dilemma

Help
1

The problem I see is that one can only set open_registration to true, otherwise nobody can register.

On the other hand, this also means the entire world can use my server (if the address is known).

Currently I have to set open_registration to true, restart the server, tell a friend that they can register, get a ping from a friend that they have registered, set open_registration to false, and restart the server again. Wash, rinse, repeat.

It would be nice to be able to provision users. There are certainly workflows where I, as the server admin, donā€™t have to know the password/key.

Is something like this planned?

2

As a temporary workaround you could add a database constraint to the username and email fields of the users table.

3

Ahhh, this is a nice one. Thanks.

Do you know what happens with the atuin server process in such a case? Is a normal error thrown or does it panic?
Such a case is not expected and the devs could have decided to panic thereā€¦

I guess Iā€™ll have to try.

4

Itā€™s not exactly planned, but Iā€™d be open to it

From what I understand, itā€™s only useful in the case of

  1. server that cannot be behind a VPN/etc
  2. server that has people register often enough that changing an env var becomes a hassle

so it hasnā€™t really been prioritised. So I can understand your use case better, how many people do you have signing up?

5

I thought about that and this means Iā€™d have to give VPN access to anyone that wants to use the atuin server. In theory possible, but could be a hassle as well, depending on the setup. Another problem is that many companies do not allow to use a VPN other than theirs, especially at the same time. So when I were in the office, I wouldnā€™t be able to sync. In that case having a public server is the only option.

I havenā€™t really thought about it. Many of my friends like working on the command line so this project would certainly be a nice addition to their daily workflow. I would have just pointed them to my server to register. Currently I can think of around 20 people (but maybe they want to host it themselves). I havenā€™t found a config paramter to limit the history, e.g. to X months or X unique commands, thus I will have to see how the storage reqs develop. Although it canā€™t be that much (doing a rough calculation in my head).

When I think a bit harder about it, this might be more of an enterprise feature. I can certainly handle changing the env var for like 20 x2 times. It was just something that came to my mind, when I was thinking about how to set it up and allow my friends to register. But you are right - restarting the server a few times is not such big deal. Itā€™s more the coordinating part that could be tricky, as in ā€œhey, please register NOW and let me know when you are doneā€.

I am also more than happy with adding a constraint to the DB table. As long as atuin does not panic because of it, that is.

6

How about requiring a shared secret - or a way to generate an invite code.

So registration, instead of just open and closed, will have an additional option - by-invite, and the command line on the server will have an option to generate an invite code with an expiration date (or an unlimited one).

This is a very common practice in sharable self-hosted solutions - allowing it to be ā€˜openā€™ to use outside of the LAN/VPN (like on travel) - but also allow friends and family access by being selective.

Of course, any other security - like blocking brute force tactics is on the server admin to setup.

1 Like
7

Yep, both worklfows came to mind when I was writing this:

The shared secret one is easier to implement (less code, no database schema changes), the invite code one is rather geared towards enteeprise usage Iā€™d say.

Both are easy to implement though. Iā€™m currently a bit busy, but Iā€™d like to help out when I have a bit more time.

P.S.: If such a feature is considered, I mean.

1 Like