Fork me on GitHub
#biff
<
2023-02-28
>
m.q.warnock19:02:58

Thanks again, @foo, for keeping things so flexible, while being very batteries-included; I'm sure it's something of a tightrope. Unfortunately, the auth plugin assumes :user/email, despite providing the option to change the transaction that it uses to create a user. My 'user' equivalent is 'author', and it's sprinkled throughout my codebase. I can work around it, and intended to write my own auth plugin anyway (I want to do invite-codes and support passwords). Will probably just change what I need in-situ for now, but if I see a clean way to provide the option in the current plugin, would you want a PR? I expect it's a very niche 'requirement' (I had a reason for them being separate at one time, but eventually merged them and favored the 'author' namespace because of how widely it's referred to, and my muscle-memory).

1
Jacob O'Bryant22:02:32

Ah yes, it does hardcode the :user/email attribute. I think an option for that would make sense; I'm thinking there could be a :biff.auth/get-user-id function with a default implementation of (fn [db email] (lookup-id db :user/email email)). A PR would be great.

👍 2
macrobartfast22:02:53

Regarding passwords, and forgive a slightly ‘off topic’ question… are traditional passwords considered a bad approach now? I mean, as opposed to emailed codes and so on. I suspect passwords are probably going to be deprecated in the future, in general, compared to other approaches.

m.q.warnock23:02:21

I don't really have my finger on the pulse, but I use so many different devices that I prefer having a password. also, I'm hella old 😉

Jacob O'Bryant23:02:21

passwords are fine, I'm just way too lazy to implement them ha ha. Basically I implemented the "forgot your password" flow and left it there. (Also the applications I'm building are email-centric anyway, so it makes sense to have people sign up the same way they would for a newsletter--just put your email in.) The main issue security-wise is just that a lot of people don't use strong passwords and/or they reuse passwords, so if you're big enough, you'll have to deal with e.g. people trying to sign in with email + password combos that have been leaked/stolen from other companies. By the time you're dealing with that, you'll have probably outgrown Biff and moved to Fulcro anyway 🙂. I'd actually be open to a PR for adding password endpoints to the auth plugin; just don't want to set aside time to do it myself yet.

macrobartfast23:02:31

Right on. I think I read somewhere online a piece that was arguing it’s time to retire the password. It made sense… except that I think passwords are a changing thing in that they are supplied by the operating system now often, or the browser/OS. The idea of my older relatives navigating 2FA is hair curling… but then again, so is the idea of how susceptible they are to phishing. I just want it to be 1952 again.

pavlosmelissinos06:03:57

Hardware security keys like yubikeys/solokeys/nitrokeys are much safer and easier to use (from the side of the user) than having to remember passwords or being "wise" enough to use a password manager and rolling your passwords often. They're non-trivial though to implement, some (older) browsers might not support it, they're not free and if you lose the key or it breaks you're locked out for good, unless you always have two keys registered in all your accounts, in which case it's practically impossible to get hacked or forget your credentials. Still, if you ask me, they're a huge step up from passwords.

m.q.warnock13:03:00

I don't think I've seen yubikeys used instead of passwords, though. I use one for all my important accounts, with authenticator backup (and sms 'backup' disabled where possible).

👍 1
Jacob O'Bryant17:03:43

I'd like to add a how-to guide for firebase auth, which is similar to auth0 but free. I assume the how-to guide would still be useful for anyone who does want to use auth0. (Last I checked auth0 seemed surprisingly expensive -- maybe they're just hoping to get you hooked with the free plan, and then by the time you start paying you're already integrated?) For the sake of limiting scope I think I won't do any 3rd party integrations in the biff auth plugin, but if anyone wants to provide a community plugin that'd be cool. Though there might be much need--auth0 etc handles the main backend routes on their servers, so you just need some frontend code for the integration, and then add some backend code to validate the JWTs that come with each request.

tbrooke18:03:02

If I can find tie I might try that the Auth0 free tier says 7000 which would more than cover my use cases — and Malcom Sparks demoed an Auth0 pluggin for Site which might be a guide

👌 2
macrobartfast20:03:55

I’m down for either firebase or auth0. However, +1 for firebase if it’s free. I can’t imagine having more than 7000 users, but boy would it suck to suddenly have to pay what is a considerable jump in price if I did exceed that. I can imagine a scenario where one gets front-paged on something and have a flood of users for that one-time-only-visit which could occupy a lot of the quota.

Jacob O'Bryant20:03:23

mm yes it sounds like a lot of users until you actually have that many

macrobartfast20:03:24

Actually, the limit to keep in mind with auth0 seems to be 10,000 when it jumps to $240 a month… yikes. It’s $23 at 7,000 users to 10,000 users.

Jacob O'Bryant21:03:47

looks like it's based on monthly active users. maybe it's not all that expensive actually, but eh. I don't even know what my MAUs are