Server auth / user management

[patrickhulce]

Server is currently unauthenticated, adding auth paves the way for UI and API calls that mutate and/or delete data

• add project-specific admin tokens (631ab01)
• delete projects route protected by admin token (0be8bdc)
• add admin token UI (feat(server): add project settings page for deletion #245)
• add project deletion UI (feat(server): add project settings page for deletion #245)
• add basic auth to server
• add basic auth to ApiClient and wizard/upload options

[patrickhulce]

Current plan here:

• Introduce a second "admin" token that is created at project creation, the admin token should never be exposed publicly in contrast to the current project token
• Require this admin token whenever data is going to be edited or deleted
• Add UI on the server side to enter your admin token that will be saved to localStorage and used for project administrative functions

Punt any more advanced multi-user management features.

[KartoffelToby]

@patrickhulce The current plan sound's good.

I have some proposals too:

• User Auth for the hole UI/API. If i'm right at this time it's only possible with htaccess or comparable
• admin Token for Add Projects via API/UI

[patrickhulce]

Thanks for the feedback @KartoffelToby!

User Auth for the hole UI/API. If i'm right at this time it's only possible with htaccess or comparable

Good suggestion 👍 we plan to accomplish this with Basic auth (updated the todo list with this)

admin Token for Add Projects via API/UI

Creating a new project has the same API-level permissions in our two-tiered model as other current requests i.e. no data is lost or destroyed. In this model, you can either allow untrusted users to create data or you don't. If you want to protect against untrusted users creating data then the server would need to use the Basic auth solution. Project creation UI itself is covered by #86.

[patrickhulce]

leaving open for basic auth story

[gulfaraz]

@patrickhulce Is it possible to set the basicAuth settings via env variables in the docker-compose file?

I see that the docker server image uses lighthouserc.json which does not have notion of environment variables.

If lighthouserc.js was used instead, then it allows us to inject env vars via the docker-compose file.

Please let me know if I'm missing a recommended approach to do setup basicAuth in the docker-compose config.

[patrickhulce]

You can still override anything set in the config with LHCI_* environment variables regardless of the type of config used (see docs). You're also free to tweak the dockerfile on your own to use lighthouserc.js if you prefer. It's just an example ;)

[gulfaraz]

@patrickhulce I used the env vars approach. It works exactly as I hoped. Thank you!

[Woitekku]

@patrickhulce @gulfaraz how this supposed to work?
`root:/usr/src/lhci# env | grep LHCI
LHCI_BASICAUTH__PASSWORD=XXXXXXXX lhci server
LHCI_BASICAUTH__USERNAME=YYYYYYYYY lhci server

root:/usr/src/lhci# ps -ef | grep lhci
root 37 8 0 09:28 ? 00:00:00 sh -c lhci server --config=./lighthouserc.json
root 38 37 0 09:28 ? 00:00:01 node /usr/src/lhci/node_modules/.bin/lhci server --config=./lighthouserc.json
root 403 76 0 09:39 pts/0 00:00:00 grep lhci
`

For unknown reason I cannot pass basic auth config via ENV VARS, what am I missing?

[patrickhulce]

@Woitekku did you try LHCI_BASIC_AUTH__PASSWORD? The option is basicAuth not basicauth so there should be an underscore in there somewhere.

[Djiit]

Hey, having the same issue here.

I guess a working example these passed as env var would help a lot:

• basicAuth.username (for server settings, e.g. on Heroku)
• basicAuth.password (for server settings, e.g. on Heroku)
• upload.extraHeaders (for the client, e.g. when your server is behind CF access or anything)

Thanks 🙏