4 ms·

I'm shocked, frankly, at how lousy both are out-of-the-box. I just don't get why a simple CRUD app (which many/most apps are) has to be so difficult. I had trou

by pbreit 11y ago

I'm shocked, frankly, at how lousy both are out-of-the-box. I just don't get why a simple CRUD app (which many/most apps are) has to be so difficult. I had trouble figuring out how to do email login on Django and just gave up. At first, Rails seems like it's going to be a lot better. I don't care for generating files. Don't like TDD. And found the migrations very confusing (if I make a typo in a field name, I delete the whole project and start over). I can't believe this is the current state of web app development. I know everyone's moved on to Node and Angular, but, c'mon!

jsmeaton 11y ago
Unfortunately it looks like you hit a bit of a sore spot with regards to django auth. There isn't a good out of the box solution for email based usernames. There are patterns available, and the "swappable" user framework is there to allow email based usernames. But an email based model isn't available. I'm fairly sure there are tickets or ideas to make this happen, but we're not there yet. Django really is quick and easy to get going though. If you can make your way past the email based usernames, I think you'd find a really capable and easy system waiting for you.
- iyn 11y ago
  One can use Custom User Models for things like email logins. I've done this in a few projects and it works great. More info: https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/1.8/topics/auth/customizin...
- japhyr 11y ago
  Do you know how well cookiecutter-django [0] handles email logins? I've been meaning to play around with cookiecutter, but I haven't started a new project recently. Cookiecutter uses django-allauth [1], which seems to offer email login methods, from what I see in a cursory look at the docs [2]. [0] - https://github.com/pydanny/cookiecutter-django https://github.com/pydanny/cookiecutter-django [1] - https://github.com/pennersr/django-allauth https://github.com/pennersr/django-allauth [2] - http://django-allauth.readthedocs.org/en/latest/configuration.html http://django-allauth.readthedocs.org/en/latest/configuratio...
  - jsmeaton 11y ago
    I asked pydanny on twitter and he says yes, thanks to django-allauth. Requires a setting in your settings.py file and it should just work.
- Alex3917 11y ago
  I think a bigger issue with regards to usernames and email is the fact that neither are titlecased before getting indexed. I get that there are certain legacy considerations or whatever, but it really seems like there should at least be a note in the documentation about this given the massive clusterfuck that would potentially ensue should someone not figure this out before launching.
  - jsmeaton 11y ago
    Do you mean that usernames/emails aren't normalised to a single case to prevent "duplicates" of "jarshwah" and "Jarshwah"? If so, this was recently brought up on the mailing list: https://groups.google.com/forum/#!topic/django-developers/SW7_qI81G58 https://groups.google.com/forum/#!topic/django-developers/SW... I agree this should probably have a solution or at least documentation to be wary of.
    - Alex3917 11y ago
      Yeah, I actually hadn't seen that, but I know there are also longstanding tickets for this. I actually don't like the solutions in those threads, I think better to just add an extra field to the models, so have something like 'db_email' and 'display_email'. I realize you can do this with a functional index or whatever, but I think that's actually kind of hacky given the lack of ORM support for functional indexes. My big issue with the current state though is that if you're relying on usernames or email addresses being unique then you're potentially opening yourself up to all sorts of security issues without realizing it.
      - jsmeaton 11y ago
        FWIW I agree the solutions in that thread aren't good enough, especially since most of them are postgres specific. Now that migrations can be shipped with contrib.auth, a better solution might be possible. I'd probably prefer a functional unique index since it would be easier to maintain (rather than duplicate fields). We just need to get expression support into indexes.
- uououuttt 11y ago
  It's comforting to know that I'm not the only one who struggled to get email-based authentication working in Django. It had me feeling totally incompentent a few weeks ago and I ended up implementing something very hackish to set the username equal to the email address.
mangeletti 11y ago
I've been using only email-based auto for years with Django. It's fully supported and very easy to use[1]. 1. https://docs.djangoproject.com/en/1.9/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD https://docs.djangoproject.com/en/1.9/topics/auth/customizin...
- pbreit 11y ago
  So that's it? I've never seen that before. Everything I saw seemed more complicated from installing various auth addons to multi-file edits and finger-crossing. And I don't see how assertions like this can be made: "This will usually be a username of some kind, but it can also be an email address" Except for HN, Twitter & Reddit, are there any services that don't use email for login?
  - jsmeaton 11y ago
    > Except for HN, Twitter & Reddit, are there any services that don't use email for login? I guess sites that use the username as a form of identity within a site. Email address usernames are just identifiers and contact information, without really being linked to an identity. I would think if auth was being written from scratch it'd probably default to email based usernames. That ship has sailed though.
    - pbreit 11y ago
      But it shouldn't have sailed. Frameworks need to keep up with the times. That should be a benefit of frameworks. Should be possible while preserving backwards compatibility.
      - Scarblac 11y ago
        Note that database migrations weren't part of Django until 1.7, before that they were provided by an external app (South). Which meant that Django's database models couldn't migrate. Even now, there is no real way to start with Django's own User model and switch your project over to a custom one later (because you'd have many database tables with foreign keys to the Django one). The current recommendation is to start new projects with a custom User model always.
moshthepitt 11y ago
Sorry about your troubles. However, you can use Django AllAuth (https://github.com/pennersr/django-allauth https://github.com/pennersr/django-allauth) to achieve an email login system by tweaking its settings. Specifically: ACCOUNT_AUTHENTICATION_METHOD = "email" ACCOUNT_USERNAME_REQUIRED = False (if you do not want to use the username field) More here: http://django-allauth.readthedocs.org/en/latest/configuration.html http://django-allauth.readthedocs.org/en/latest/configuratio... Cheers!
jonesb6 11y ago
I think this is more a flaw of the authoritarian nature of larger web frameworks. They can't cater to every use case and have to be opinionated in certain areas. In Django's case I would say their Authentication model was an opinionated choice that has since become a major staple of Django. Many frameworks will not include default ORM-models and will instead defer to the user to implement their own authentication scheme. Personally I disagree with this choice, I think database schemas have to be flexible and an in-framework authentication setup will only encourage users to lean more on the framework even when it is working against them. I've burned plenty of hours in Django trying to work / extend the authentication model. While I have no doubt much of this was due to my inexperience with Django, there is a certain responsibility with having a framework used by many beginners who will struggle and perhaps pick up bad habits (like expecting your web framework to automagically solve everything) if you do not design it for them. Overall I think Django is awesome. But it's not for every use-case, or every developer. About a year ago I moved over to NodeJS professionaly, some day I will perhaps go back but have yet to have any significant reason to do so.

by pbreit 11y ago

jsmeaton 11y ago

Unfortunately it looks like you hit a bit of a sore spot with regards to django auth. There isn't a good out of the box solution for email based usernames. There are patterns available, and the "swappable" user framework is there to allow email based usernames. But an email based model isn't available. I'm fairly sure there are tickets or ideas to make this happen, but we're not there yet. Django really is quick and easy to get going though. If you can make your way past the email based usernames, I think you'd find a really capable and easy system waiting for you.

iyn 11y ago
One can use Custom User Models for things like email logins. I've done this in a few projects and it works great. More info: https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/1.8/topics/auth/customizin...
japhyr 11y ago
Do you know how well cookiecutter-django [0] handles email logins? I've been meaning to play around with cookiecutter, but I haven't started a new project recently. Cookiecutter uses django-allauth [1], which seems to offer email login methods, from what I see in a cursory look at the docs [2]. [0] - https://github.com/pydanny/cookiecutter-django https://github.com/pydanny/cookiecutter-django [1] - https://github.com/pennersr/django-allauth https://github.com/pennersr/django-allauth [2] - http://django-allauth.readthedocs.org/en/latest/configuration.html http://django-allauth.readthedocs.org/en/latest/configuratio...
- jsmeaton 11y ago
  I asked pydanny on twitter and he says yes, thanks to django-allauth. Requires a setting in your settings.py file and it should just work.
Alex3917 11y ago
I think a bigger issue with regards to usernames and email is the fact that neither are titlecased before getting indexed. I get that there are certain legacy considerations or whatever, but it really seems like there should at least be a note in the documentation about this given the massive clusterfuck that would potentially ensue should someone not figure this out before launching.
- jsmeaton 11y ago
  Do you mean that usernames/emails aren't normalised to a single case to prevent "duplicates" of "jarshwah" and "Jarshwah"? If so, this was recently brought up on the mailing list: https://groups.google.com/forum/#!topic/django-developers/SW7_qI81G58 https://groups.google.com/forum/#!topic/django-developers/SW... I agree this should probably have a solution or at least documentation to be wary of.
  - Alex3917 11y ago
    Yeah, I actually hadn't seen that, but I know there are also longstanding tickets for this. I actually don't like the solutions in those threads, I think better to just add an extra field to the models, so have something like 'db_email' and 'display_email'. I realize you can do this with a functional index or whatever, but I think that's actually kind of hacky given the lack of ORM support for functional indexes. My big issue with the current state though is that if you're relying on usernames or email addresses being unique then you're potentially opening yourself up to all sorts of security issues without realizing it.
    - jsmeaton 11y ago
      FWIW I agree the solutions in that thread aren't good enough, especially since most of them are postgres specific. Now that migrations can be shipped with contrib.auth, a better solution might be possible. I'd probably prefer a functional unique index since it would be easier to maintain (rather than duplicate fields). We just need to get expression support into indexes.
uououuttt 11y ago
It's comforting to know that I'm not the only one who struggled to get email-based authentication working in Django. It had me feeling totally incompentent a few weeks ago and I ended up implementing something very hackish to set the username equal to the email address.

mangeletti 11y ago

I've been using only email-based auto for years with Django. It's fully supported and very easy to use[1]. 1. https://docs.djangoproject.com/en/1.9/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD https://docs.djangoproject.com/en/1.9/topics/auth/customizin...

pbreit 11y ago
So that's it? I've never seen that before. Everything I saw seemed more complicated from installing various auth addons to multi-file edits and finger-crossing. And I don't see how assertions like this can be made: "This will usually be a username of some kind, but it can also be an email address" Except for HN, Twitter & Reddit, are there any services that don't use email for login?
- jsmeaton 11y ago
  > Except for HN, Twitter & Reddit, are there any services that don't use email for login? I guess sites that use the username as a form of identity within a site. Email address usernames are just identifiers and contact information, without really being linked to an identity. I would think if auth was being written from scratch it'd probably default to email based usernames. That ship has sailed though.
  - pbreit 11y ago
    But it shouldn't have sailed. Frameworks need to keep up with the times. That should be a benefit of frameworks. Should be possible while preserving backwards compatibility.
    - Scarblac 11y ago
      Note that database migrations weren't part of Django until 1.7, before that they were provided by an external app (South). Which meant that Django's database models couldn't migrate. Even now, there is no real way to start with Django's own User model and switch your project over to a custom one later (because you'd have many database tables with foreign keys to the Django one). The current recommendation is to start new projects with a custom User model always.

moshthepitt 11y ago

Sorry about your troubles. However, you can use Django AllAuth (https://github.com/pennersr/django-allauth https://github.com/pennersr/django-allauth) to achieve an email login system by tweaking its settings. Specifically: ACCOUNT_AUTHENTICATION_METHOD = "email" ACCOUNT_USERNAME_REQUIRED = False (if you do not want to use the username field) More here: http://django-allauth.readthedocs.org/en/latest/configuration.html http://django-allauth.readthedocs.org/en/latest/configuratio... Cheers!

jonesb6 11y ago

I think this is more a flaw of the authoritarian nature of larger web frameworks. They can't cater to every use case and have to be opinionated in certain areas. In Django's case I would say their Authentication model was an opinionated choice that has since become a major staple of Django. Many frameworks will not include default ORM-models and will instead defer to the user to implement their own authentication scheme. Personally I disagree with this choice, I think database schemas have to be flexible and an in-framework authentication setup will only encourage users to lean more on the framework even when it is working against them. I've burned plenty of hours in Django trying to work / extend the authentication model. While I have no doubt much of this was due to my inexperience with Django, there is a certain responsibility with having a framework used by many beginners who will struggle and perhaps pick up bad habits (like expecting your web framework to automagically solve everything) if you do not design it for them. Overall I think Django is awesome. But it's not for every use-case, or every developer. About a year ago I moved over to NodeJS professionaly, some day I will perhaps go back but have yet to have any significant reason to do so.