Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add auth #70

Open
Tracked by #10
pwbriggs opened this issue Mar 10, 2024 · 2 comments · May be fixed by #153
Open
Tracked by #10

Add auth #70

pwbriggs opened this issue Mar 10, 2024 · 2 comments · May be fixed by #153
Assignees
Labels
discussion Needs a choice to be made before proceeding todo Todo items during heavy development

Comments

@pwbriggs
Copy link
Owner

pwbriggs commented Mar 10, 2024

Implement authorization and user creation.

Libraries are different from many other systems in that accounts cannot be created by just anybody. A librarian (or admin) needs to create user accounts for the patrons. Likewise, an admin creates librarian accounts (or rather, elevates the permissions of a patron).

But then where do admins come from?

My best idea so far is to have some config (.env file?) with an initial admin password. Somewhere on the site (probably root route or login page) we do the following:

  • If no admin accounts exist (or perhaps no accounts at all? there's pros and cons to each), show message to the effect of "This server isn't configured properly. Please contact your library. If you are the operator of this server, please add a SETUP_PASSWORD entry to the config file."
  • If no admin accounts exist and the initial password is configured, create a new admin account.
  • If an admin account does exist and the initial password is configured, give a warning similar to the one above, saying to remove the file. This is for security reasons (we don't want a situation where an account is being auto-created accidentally).

Problem is, the vast majority of the time will be the happy path, so how do we avoid unnecessary requests? Can we run the database query only on server startup?

It would be nice if this could just be prompted on server startup. However, some setups might not allow interaction with the command line of the deployment machine.

@pwbriggs pwbriggs added this to the Initial release milestone Mar 10, 2024
@pwbriggs pwbriggs added todo Todo items during heavy development discussion Needs a choice to be made before proceeding labels Mar 10, 2024
@pwbriggs pwbriggs self-assigned this Mar 10, 2024
@pwbriggs
Copy link
Owner Author

pwbriggs commented Jul 9, 2024

Eh, we could simplify that workflow: just refuse to start if no admin exists (or one does but the .env token is defined). We still need something for creating an actual account with the token, but it removes the need for an expensive query more often than I'd like.

While some setups (cloud providers, etc.) mightn't allow interaction with a CLI, anything reasonable would at least display an error message we print on startup.

@pwbriggs pwbriggs linked a pull request Jul 14, 2024 that will close this issue
7 tasks
@pwbriggs
Copy link
Owner Author

pwbriggs commented Jul 14, 2024

So here's an idea: we create a "one-time token" credential.1 This can be used for user creations (and password resets) in general, but also to bootstrap the initial admin account.

Then we can just generate a token on startup if there isn't an admin, and hopefully figure out a clean way to close down the server and politely refuse regular user traffic with some awkward error page.

Footnotes

  1. See Implement user creation and login #153: auth methods are very flexible and it should (hopefully) be easy to wire up a new method like this. It will need some special logic though to delete itself after use.

@pwbriggs pwbriggs linked a pull request Jul 14, 2024 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Needs a choice to be made before proceeding todo Todo items during heavy development
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant