Please add regular password auth!

[mrjones2014]

This software looks really great! I would love to self host it on my server to manage my home ownership projects.

However, I do not want to have to set up SMTP and I really, really dislike magic email auth.

Could there be a feature flag or environment variable or something that would enable regular password auth?

[daz-codes]

I imagine you're going to have to look at implementing this yourself ... or somebody else will!

[flavorjones]

I think we're open to accepting code contributions for improved and more flexible authentication options, but we don't have plans right now to do this ourselves at 37signals.

If you're interested in contributing this, let us know and we're happy to give feedback and advice!

[mrjones2014]

I have never written Ruby before but maybe I will give it a shot 😅

[daz-codes]

I might try having a go at it. The auth generator produces what you’re after but still includes email to validate the email address. Would you be happy doing without that?

[mrjones2014]

I would rather not have to set up SMTP at all, and I only plan on exposing it to a small LAN of trusted users (you have to connect to a WireGuard VPN to access my server), so yeah, more than happy with that.

Feel free to ping me, I'm happy to help out however I can.

[dpshde]

Went ahead and threw this together #2027

[mrjones2014]

Awesome! I'd be more than happy with Passkeys!

[jzimdars]

On principle, I think we're more likely to go with passkeys as an alternate auth option rather than traditional passwords.

[dpshde]

This would satisfy my problems! I too can't stand email auth only

[dpshde]

Gave this a go with the help of Claude Code #2027

[jmesterh]

A bit of anecdata: after watching the intro video and thinking maybe I'll give it a shot, I was disappointed to find no SSO support, and then wrote off the entire thing when I saw it was magic email auth only. Forcing people to look at their unread emails, and likely noticing something even more important than logging into to Fizzy seems to go against the entire philosophy in the intro video. I truly hope you reconsider this in the future, because otherwise this looks great.

[northeastprince]

I think the main thinking here is that the number of times you'll actually have to go through this process is pretty small. Same with GitHub, Basecamp, etc. So it's much less of an annoyance in practice since it's usually only needed once per device, and that's quite a bit of technical work saved that can be better spent elsewhere.

[cerebrate]

Of course, if going through the process requires all the technical work of setting up an internal mail server, that flips back the other way.

[schewara]

I think the main thinking here is that the number of times you'll actually have to go through this process is pretty small.

For me it looks like there is no real session lifetime setting, but instead relying on things stored in the local browser cache.

Session, token or whatever lifetime should be configurable and not last forever, to prevent bad actors to hijack some old session depending on how the browsers cache cleanup is configured.

🙈

In a more security sensitive environment, the current solution does raise many eyebrows and will cause friction quite quickly when global browser policies require daily cache cleanup or other measures.

[nv-zhangineer]

I would love to have the ability to use passkey sign-in for self-hosting. This is preventing me from using this amazing software for my internal team use. We would self host this due to data sensitivity and there is no path for me to setup email forwarding/SMTP at all since it's all corporate managed infrastructure.

[clayrisser]

Lack of SSO is a dealbreaker.

[jgmontoya]

Not having a regular password auth makes it way harder for self-hosted users. I might give it a try if I find the time to do it.

[estevao]

I'm using gmail as smtp for Fizzy, easy to configure and will unblock you right away if what you want is to get access.

Put the below in your docker-compose.yml:

SMTP_ADDRESS: smtp.gmail.com
SMTP_PORT: 587
SMTP_USERNAME: <your_email>@gmail.com
SMTP_PASSWORD: <your 16 character gmail app password - generate it on gmail security settings>
SMTP_AUTHENTICATION: plain
SMTP_ENABLE_STARTTLS_AUTO: true
SMTP_SSL: false
SMTP_OPENSSL_VERIFY_MODE: none
MAILER_FROM_ADDRESS: fizzy@localhost

[cerebrate]

Question: does #2623 being merged imply that passkeys will be coming soon? And if so, for signup as well as sign-in?

[davidawad]

just chiming in to add my agreement, I have no idea why the additional auth options have to detract from anyone else's usage. there is no cost and only benefit to having the additional options for other usecases.

I was going to try this today and couldn't because I needed to setup a mailserver for it which became too annoying to figure out as I have no spare time.

please add password auth and all the other auth options other commenters mentioned, why not.