forked from tildetown/town
README cleanup
parent
8fb6208dbf
commit
76bf2643a6
|
@ -1,25 +1,11 @@
|
|||
THIS COMMAND is for reviewing applications made to tilde.town. it's for admins to run.
|
||||
|
||||
signups land in `/town/signups` as JSON files. This tool iterates over them and
|
||||
lets an admin take one of a few actions:
|
||||
Signups are read from /town/var/signups/signups.db . Approved signups create rows in /town/var/invites/invites.db .
|
||||
|
||||
# verbs in the TUI:
|
||||
|
||||
- skip
|
||||
- approve
|
||||
- reject
|
||||
- notate (leave a note for other admins)
|
||||
- jump to random signup
|
||||
|
||||
some other requirements in no particular order:
|
||||
|
||||
- JSON files should be locked when being looked at
|
||||
- notation modifies the JSON in place
|
||||
- approved signups go to `/town/signups/approved`
|
||||
- rejected signups go to `/town/signups/rejected`
|
||||
|
||||
I'm not 100% sure yet what approval is going to look like; I want to switch to
|
||||
a system where people are emailed about their acceptance and given a code they
|
||||
can exchange for an ssh form that lets them pick a username and add a pubkey.
|
||||
|
||||
so for now i'm just going to move the files into `/town/signups/approved` while
|
||||
i think about that.
|
||||
|
||||
|
|
|
@ -1,4 +1,5 @@
|
|||
# town signup
|
||||
|
||||
The point of this command is to enable signing up for tilde.town via an ssh connection. It is designed to be run when `join@tilde.town` is SSH'd to.
|
||||
|
||||
## to-dos
|
||||
|
@ -9,21 +10,13 @@ The point of this command is to enable signing up for tilde.town via an ssh conn
|
|||
- [x] write answers to disk
|
||||
- [x] take out sidebar
|
||||
- [x] add /help
|
||||
- [ ] make copy clearer (that you say whatever and *then* type verb)
|
||||
- [x] make copy clearer (that you say whatever and *then* type verb)
|
||||
- [x] enter to send
|
||||
- [ ] splash screen - put off
|
||||
- [ ] easter egg commands - put off
|
||||
- [ ] inactivity timer(?) - put off
|
||||
- [ ] review tool
|
||||
- [x] iterate over answers
|
||||
- [ ] accept
|
||||
- [ ] notate
|
||||
- [ ] reject
|
||||
- [ ] send email with directions on key upload
|
||||
- [ ] actual account creation
|
||||
- [ ] accept key
|
||||
- [ ] accept username
|
||||
- [ ] create user
|
||||
- [x] review tool
|
||||
- [x] actual account creation
|
||||
- [ ] backlog
|
||||
- [ ] get a manual dump from psql of json
|
||||
- [ ] convert into files in the review directory
|
||||
|
|
|
@ -6,8 +6,9 @@ responsible for:
|
|||
1. accepting and validating an invite token generated by the `review` command
|
||||
2. accepting and validating a new user's username choice (ie enforcing rules and checking for dupes)
|
||||
3. accepting and validating a user's email for use in account recovery (defaulting to an email embedded in the invite token)
|
||||
4. accepting and validating a display name
|
||||
5. accepting and validating a user's public ssh key
|
||||
4. accepting and validating a display name (PUT OFF)
|
||||
5. Confirming that a user agrees to our CoC
|
||||
6. accepting and validating a user's public ssh key
|
||||
|
||||
upon receipt of these things a user account is created. if it fails, the user
|
||||
is told about the failure and told to email root@tilde.town for guidance; us
|
||||
|
@ -26,10 +27,10 @@ an invite token consists of two pieces that are then base64 encoded. the first p
|
|||
something like:
|
||||
|
||||
```
|
||||
welcome ALL=(ALL)NOPASSWD:/usr/sbin/adduser,/usr/sbin/usermod,/bin/mkdir,/town/bin/generate_welcome_present.sh,/town/bin/create_keyfile
|
||||
welcome ALL=(ALL)NOPASSWD:/usr/sbin/adduser,/usr/sbin/usermod,/town/bin/createkeyfile,/town/bin/generate_welcome_present.sh,/town/bin/registeruser
|
||||
```
|
||||
|
||||
though I will likely move welcome_present generation inline to `welcome` itself.
|
||||
I'd like to consolidate adduser/usermod calls into a single "createuser" helper. I'd also like to move the welcome present generation into `welcome`. TODO.
|
||||
|
||||
## user creation flow
|
||||
|
||||
|
|
Loading…
Reference in New Issue