How to implement authentication for peach-web #6

New Issue

notplants · 2021-10-27T11:51:14Z

notplants commented

2021-10-27 11:51:14 +00:00

I'm starting this issue to write down some of my research.

I need to look more into rocket_auth crate, and see if its worth using,
but I atleast have a few good references on how we can implement simple username/password authentication using cookies (this may be fine for us, as I'm not sure we will need the type of complicated oauth flows you need when you have multiple possible login types).

Plume also uses simple authentication like this. They use a RequestGuard, which fetches a user from the cookie, and returns "logged in" if it works, and redirects you to login, if it doesn't work.
On line 914 here:
https://github.com/Plume-org/Plume/blob/main/plume-models/src/users.rs

That's similar to the approach described in detail in this blog post (https://medium.com/@james_32022/authentication-in-rocket-feb4f7223254), with a code example here: https://github.com/MondayMorningHaskell/RustWeb/blob/master/src/bin/rocket_auth.rs

This library does something similar, (https://github.com/bramvdbogaerde/auth-rs/blob/master/example/src/main.rs), but perhaps using this library is more trouble than its worth.

I'm starting this issue to write down some of my research. I need to look more into rocket_auth crate, and see if its worth using, but I atleast have a few good references on how we can implement simple username/password authentication using cookies (this may be fine for us, as I'm not sure we will need the type of complicated oauth flows you need when you have multiple possible login types). Plume also uses simple authentication like this. They use a RequestGuard, which fetches a user from the cookie, and returns "logged in" if it works, and redirects you to login, if it doesn't work. On line 914 here: https://github.com/Plume-org/Plume/blob/main/plume-models/src/users.rs That's similar to the approach described in detail in this blog post (https://medium.com/@james_32022/authentication-in-rocket-feb4f7223254), with a code example here: https://github.com/MondayMorningHaskell/RustWeb/blob/master/src/bin/rocket_auth.rs This library does something similar, (https://github.com/bramvdbogaerde/auth-rs/blob/master/example/src/main.rs), but perhaps using this library is more trouble than its worth.

👍 1

notplants added the

enhancement

peach-web

labels 2021-10-27 11:51:15 +00:00

notplants commented

2021-10-29 10:34:10 +00:00

This morning I looked into detail in the rocket_auth library https://github.com/tvallotton/rocket_auth

It looks pretty nice, and has an integration with Sqlite, but it expects login to be with an email and password, and hardcodes email validation.

For our app, I imagine we use ssb_id as the username, instead of email, since we are doing all notifs and stuff through ssb, and we have no email stack anyway.

So if we want to use this library, we would NEED to fork it, and get rid of these email validation lines. An additional change that would not be necessary, just cosmetic, but also would be nice to change all references to the word "email" to "username" in the fork, so that we don't strangely use functions like user.set_email ... when really we mean username.

I'm not sure forking is worth what we gain, since really rocket_auth is just some wrappers for the the manual way that Plume is doing... using cookies and RequestGuards

This morning I looked into detail in the rocket_auth library https://github.com/tvallotton/rocket_auth It looks pretty nice, and has an integration with Sqlite, but it expects login to be with an email and password, and hardcodes email validation. For our app, I imagine we use ssb_id as the username, instead of email, since we are doing all notifs and stuff through ssb, and we have no email stack anyway. So if we want to use this library, we would NEED to fork it, and get rid of these email validation lines. An additional change that would not be necessary, just cosmetic, but also would be nice to change all references to the word "email" to "username" in the fork, so that we don't strangely use functions like user.set_email ... when really we mean username. I'm not sure forking is worth what we gain, since really rocket_auth is just some wrappers for the the manual way that Plume is doing... using cookies and RequestGuards

👍 1

notplants commented

2021-11-01 12:42:30 +00:00

delta (https://github.com/revoltchat/delta) uses rauth (https://github.com/insertish/rauth) for authentication

however, again this library appears to depend on email.

if we want to ditch the dependence on emails, perhaps we should just manually do authentication with cookies, like Plume, but using ssb_ids

delta (https://github.com/revoltchat/delta) uses rauth (https://github.com/insertish/rauth) for authentication however, again this library appears to depend on email. if we want to ditch the dependence on emails, perhaps we should just manually do authentication with cookies, like Plume, but using ssb_ids

glyph commented

2021-11-01 15:09:32 +00:00

Thanks for sharing your research!

I agree that forking rocket_auth is not a desirable path.

perhaps we should just manually do authentication with cookies, like Plume, but using ssb_ids

I'm down to try this. It's an option which allows us to keep peach-web lean (without needing additional dependencies), learn more about Rocket and support ssb_id as the primary user identifier.

Thanks for sharing your research! I agree that forking rocket_auth is not a desirable path. > perhaps we should just manually do authentication with cookies, like Plume, but using ssb_ids I'm down to try this. It's an option which allows us to keep peach-web lean (without needing additional dependencies), learn more about Rocket and support `ssb_id` as the primary user identifier.

glyph commented

2021-11-01 16:17:35 +00:00

It also occurred to me, while out on my evening stroll, that you might want to talk to @staltz about ssb auth (I believe he implemented this in rooms - without need for a password). There are trade-offs for password-based auth vs. keypair auth.