5 ms·

My "pain point" is a bit earlier in the process: Auser authentification. What is everyone using for this? How do you turn a static website where a user can se

by TekMol 5y ago

My "pain point" is a bit earlier in the process: Auser authentification. What is everyone using for this? How do you turn a static website where a user can set some configurations (say the color scheme) into a site where the user can log in and save their settings? In the past I rolled my own solutions. But for new projects I am considering to use a library or framework. I guess Django, Flask, Laravel, Symfony and Express all come with some default auth mechanism. How is HNs experience? Are you using these? Are you happy with them?

Cicero22 5y ago
You shouldn't be rolling your own authentication. That's just asking for trouble. I don't have experience with those frameworks, but the rails equivalent, devise, is very good. I assume it's the same for any mature framework.
- ipaddr 5y ago
  Rolling his own doesn't mean custom algos. It means he will use the buildin language functions and/or external packages for that functionality while manually piping all of the pieces together. He is not asking for trouble..
  - Cicero22 5y ago
    While you can definitely manually pipe all of the pieces together and have a functioning system, it's significantly easier, and likely more secure, to use the battle-tested auth library of a framework. One could also use the builtin language functionality and external packages to write custom crypto, and I think we'd both agree that that's a bad idea. I'd argue that it's the same for authentication in general.
    - ipaddr 5y ago
      I understand that point of view and I agree for the majority of projects but relying on a fully working system that is coupled to some structure can be limiting if you need to make something slightly different. I see a frameworks like laraval as the middle path where you can rely on the framework to handle auth but also can make any changes you may need.
view 5y ago
I love using Firebase Auth: https://firebase.google.com/docs/auth https://firebase.google.com/docs/auth
- TekMol 5y ago
  I looked through the docs and have some issues with it. First of all, it is a service. That opens a can of worms on its own. The main issue being that you are 100% at the mercy of the service provider. Every time they decide to change their API, it adds maintenance work to your project. Sometimes it happens on short notice which can be very annoying. Second, it is a strange mix of service and code. I don't see an easy way to use it without their Javascript SDK. And installing that SDK looks complicated from what I see.
  - steve_adams_86 5y ago
    To use it without the JS SDK, you need to create a server which integrates with their API. This usually means pulling an SDK in on your server which is often okay, though I did find their Go SDK (https://github.com/firebase/firebase-admin-go https://github.com/firebase/firebase-admin-go) rough on the edges. We ultimately abandoned using the service... I think if your integration requires any fine tuning or integration with other services, you might want to look elsewhere.
- steve_adams_86 5y ago
  My team tried Firebase Auth and while I think it's stellar for some use cases, I'd warn people about some potential issues: - Firebase is a juggernaut of a library on the frontend: https://bundlephobia.com/package/firebase@8.10.0 https://bundlephobia.com/package/firebase@8.10.0 Our product's main feature is being fast - it has the word "instant" in the name. For a product with users around the world, many of them will feel that network request and/or increased execution time. This is fine at the prototype stage or for teams which don't have the resources to implement a case-specific auth implementation that'll be lightweight and efficient. In our case we felt kind of stupid; this should have been clear to us from the beginning, but we wanted to move quickly. Ultimately this cost us time, and to be frank, that was mostly on me! - Integration with other systems wasn't always smooth or simple. The Firebase Admin documentation left a lot to be desired. There are a lot of quirks all over. Some fields during some authentications might be empty for example, but it wasn't clear why or what this meant - this meant a lot of deep-diving and experimentation. We were using the official Go library. Sometimes we could use the library, other times we'd need to write a request out to Google's APIs. We made a lot of passes to improve on this thinking we must be missing something, but after hitting various existing issues online where developers dismissed the problem, it became clear that this is just life for a Go server supporting Firebase Admin. I do recall that Android and Node.js support appeared much better, so if you suspect you're using a better-supported ecosystem, maybe this won't get in your way. - Something that a better developer might understand and navigate than I did was the lack of assurance of data being present or its structure being consistent. Fields coming back for users seemed slightly inconsistent (not a problem for most requests). I wrote a parser for each provider to normalize data because occasionally we'd be missing the user's email or something. For example, as I recall, getting the email from a Twitter-authed user could be different from getting the email for a Google-authed user. I'll admit we had other issues to face so I spent the least time on this, then we dropped Firebase before I could revisit. - Like any off-the-shelf solution, it ends up having significant limitations. This can be a great thing too, but for us it was a deal breaker. You can assign metadata to auth profiles but this felt too flimsy to us. I think this is a general Firebase issue, not specific only to auth: data integrity is poor. It was an ever-present problem that we couldn't attach users to our other data with rock solid guarantees. It felt like auth was almost ephemeral in our stack, and without fully owning it, it was as though our users weren't the cornerstone of our application but a floating member out in space. Despite all of that it's a great product and I highly recommend it if it fits your needs. I'm not slamming the developers behind it. I think they're well aware that it's not for everyone, and they've done a great job making it work for as many people as it does.
bordakt 5y ago
You should look into Keycloak. It is an open source identity and access manager.
- TekMol 5y ago
  Thanks. For how long have you been using it?
  - nprateem 5y ago
    Don't bother. Unless you're building enterprise apps that need to support OIDC it's completely the wrong product for making a static site a bit more interactive.
PaulHoule 5y ago
It was funny that I built a "user management" framework that was open source in 2001 and nobody cared except for crackers.
danpalmer 5y ago
We use Django's authentication, authorisation, and session management and it's rock solid. I can highly recommend it.
- TekMol 5y ago
  Did you have to create all the usual routes and views for the typical auth flow like signup, login, logout, change-password etc yourself? I did a quick test like this: apt install -y python3-django django-admin startproject mysite cd mysite python3 manage.py migrate python3 manage.py runserver 0.0.0.0:80 And it serves a Django site but there seem to be no routes for users to sign up, log in etc. The urls.py file contains only this one route it seems: urlpatterns = [ url(r'^admin/', admin.site.urls), ]
  - danpalmer 5y ago
    Django provides views for all of these things that you can inherit from to customise if you want. We happen to deviate from Django's norms enough that we've written our own, but there are a lot of benefits to basing your own on Django's because they have already solved some more subtle security issues like rotating session keys at the right stages.
    - TekMol 5y ago
      I digged a bit deeper now and see Django indeed offers default views. But it does not offer default templates, so you still have to write those from scratch, right?
Natfan 5y ago
I'd go with Supabase.
- TekMol 5y ago
  Thanks. I have been reading through the docs for a while now but I am not sure what to make of it. What would be the minimum number of commands I have to type into a command line (Say in a fresh Debian install) to get a simple site up and running that lets users do the basic stuff like sign up, log in, log out, change password, delete profile?
  - kiwicopple 5y ago
    There are some guides in the docs which cover Database + Auth + Storage. They take about 10 mins to work through. (For example, with React: https://supabase.io/docs/guides/with-react https://supabase.io/docs/guides/with-react) Auth: const { error } = await supabase.auth.signIn({ email }) Storage: let { error } = await supabase.storage .from('avatars') .upload(filePath, file)

by TekMol 5y ago

Cicero22 5y ago

You shouldn't be rolling your own authentication. That's just asking for trouble. I don't have experience with those frameworks, but the rails equivalent, devise, is very good. I assume it's the same for any mature framework.

ipaddr 5y ago
Rolling his own doesn't mean custom algos. It means he will use the buildin language functions and/or external packages for that functionality while manually piping all of the pieces together. He is not asking for trouble..
- Cicero22 5y ago
  While you can definitely manually pipe all of the pieces together and have a functioning system, it's significantly easier, and likely more secure, to use the battle-tested auth library of a framework. One could also use the builtin language functionality and external packages to write custom crypto, and I think we'd both agree that that's a bad idea. I'd argue that it's the same for authentication in general.
  - ipaddr 5y ago
    I understand that point of view and I agree for the majority of projects but relying on a fully working system that is coupled to some structure can be limiting if you need to make something slightly different. I see a frameworks like laraval as the middle path where you can rely on the framework to handle auth but also can make any changes you may need.

view 5y ago

I love using Firebase Auth: https://firebase.google.com/docs/auth https://firebase.google.com/docs/auth

TekMol 5y ago
I looked through the docs and have some issues with it. First of all, it is a service. That opens a can of worms on its own. The main issue being that you are 100% at the mercy of the service provider. Every time they decide to change their API, it adds maintenance work to your project. Sometimes it happens on short notice which can be very annoying. Second, it is a strange mix of service and code. I don't see an easy way to use it without their Javascript SDK. And installing that SDK looks complicated from what I see.
- steve_adams_86 5y ago
  To use it without the JS SDK, you need to create a server which integrates with their API. This usually means pulling an SDK in on your server which is often okay, though I did find their Go SDK (https://github.com/firebase/firebase-admin-go https://github.com/firebase/firebase-admin-go) rough on the edges. We ultimately abandoned using the service... I think if your integration requires any fine tuning or integration with other services, you might want to look elsewhere.
steve_adams_86 5y ago
My team tried Firebase Auth and while I think it's stellar for some use cases, I'd warn people about some potential issues: - Firebase is a juggernaut of a library on the frontend: https://bundlephobia.com/package/firebase@8.10.0 https://bundlephobia.com/package/firebase@8.10.0 Our product's main feature is being fast - it has the word "instant" in the name. For a product with users around the world, many of them will feel that network request and/or increased execution time. This is fine at the prototype stage or for teams which don't have the resources to implement a case-specific auth implementation that'll be lightweight and efficient. In our case we felt kind of stupid; this should have been clear to us from the beginning, but we wanted to move quickly. Ultimately this cost us time, and to be frank, that was mostly on me! - Integration with other systems wasn't always smooth or simple. The Firebase Admin documentation left a lot to be desired. There are a lot of quirks all over. Some fields during some authentications might be empty for example, but it wasn't clear why or what this meant - this meant a lot of deep-diving and experimentation. We were using the official Go library. Sometimes we could use the library, other times we'd need to write a request out to Google's APIs. We made a lot of passes to improve on this thinking we must be missing something, but after hitting various existing issues online where developers dismissed the problem, it became clear that this is just life for a Go server supporting Firebase Admin. I do recall that Android and Node.js support appeared much better, so if you suspect you're using a better-supported ecosystem, maybe this won't get in your way. - Something that a better developer might understand and navigate than I did was the lack of assurance of data being present or its structure being consistent. Fields coming back for users seemed slightly inconsistent (not a problem for most requests). I wrote a parser for each provider to normalize data because occasionally we'd be missing the user's email or something. For example, as I recall, getting the email from a Twitter-authed user could be different from getting the email for a Google-authed user. I'll admit we had other issues to face so I spent the least time on this, then we dropped Firebase before I could revisit. - Like any off-the-shelf solution, it ends up having significant limitations. This can be a great thing too, but for us it was a deal breaker. You can assign metadata to auth profiles but this felt too flimsy to us. I think this is a general Firebase issue, not specific only to auth: data integrity is poor. It was an ever-present problem that we couldn't attach users to our other data with rock solid guarantees. It felt like auth was almost ephemeral in our stack, and without fully owning it, it was as though our users weren't the cornerstone of our application but a floating member out in space. Despite all of that it's a great product and I highly recommend it if it fits your needs. I'm not slamming the developers behind it. I think they're well aware that it's not for everyone, and they've done a great job making it work for as many people as it does.

bordakt 5y ago

You should look into Keycloak. It is an open source identity and access manager.

TekMol 5y ago
Thanks. For how long have you been using it?
- nprateem 5y ago
  Don't bother. Unless you're building enterprise apps that need to support OIDC it's completely the wrong product for making a static site a bit more interactive.

PaulHoule 5y ago

It was funny that I built a "user management" framework that was open source in 2001 and nobody cared except for crackers.

danpalmer 5y ago

We use Django's authentication, authorisation, and session management and it's rock solid. I can highly recommend it.

TekMol 5y ago
Did you have to create all the usual routes and views for the typical auth flow like signup, login, logout, change-password etc yourself? I did a quick test like this: apt install -y python3-django django-admin startproject mysite cd mysite python3 manage.py migrate python3 manage.py runserver 0.0.0.0:80 And it serves a Django site but there seem to be no routes for users to sign up, log in etc. The urls.py file contains only this one route it seems: urlpatterns = [ url(r'^admin/', admin.site.urls), ]
- danpalmer 5y ago
  Django provides views for all of these things that you can inherit from to customise if you want. We happen to deviate from Django's norms enough that we've written our own, but there are a lot of benefits to basing your own on Django's because they have already solved some more subtle security issues like rotating session keys at the right stages.
  - TekMol 5y ago
    I digged a bit deeper now and see Django indeed offers default views. But it does not offer default templates, so you still have to write those from scratch, right?

Natfan 5y ago

I'd go with Supabase.

TekMol 5y ago
Thanks. I have been reading through the docs for a while now but I am not sure what to make of it. What would be the minimum number of commands I have to type into a command line (Say in a fresh Debian install) to get a simple site up and running that lets users do the basic stuff like sign up, log in, log out, change password, delete profile?
- kiwicopple 5y ago
  There are some guides in the docs which cover Database + Auth + Storage. They take about 10 mins to work through. (For example, with React: https://supabase.io/docs/guides/with-react https://supabase.io/docs/guides/with-react) Auth: const { error } = await supabase.auth.signIn({ email }) Storage: let { error } = await supabase.storage .from('avatars') .upload(filePath, file)