The Software Detective - Django Authentication

As I move through the Django upgrade of my OpenEats fork, I also continue to double down on my philosophy that it's better to build from a previous foundation than it is to just write new code.  In today's argument to that effect, I'll use the site's authentication system as an example.

The current OpenEats site uses a combination of django registration redux and the framework's authentication module.  It also places login and sign up logic on the same page as separate tabs and makes calls to those individual functions via ajax.  I don't find anything wrong with this approach, but it seems a bit complicated in its design, so I decided to separate the two functions out into separate pages without ajax calls.

Now, if I were to do this as a green field project, I likely would have looked up the framework's authentication module and got a lot of the login/logout/password reset goodness that comes with it, but I wouldn't have found the additional registration functionality that comes with the redux app.  I may have stumbled on to redux if I were researching alternative authentication modules, but it would have been one of many.  The fact that I may have chosen something else isn't bad, but I probably would have spent too much time looking at the pros and cons of each module than simply selecting something, testing it, and moving on.  Because redux was already there, it reduced the decision space I had to wander through.  Also, because the redux functionality is pretty comprehensive, but the documentation hasn't yet caught up, I needed to read through the redux source code (which is pretty easy to follow, btw).  The end of the README also led me to a possible replacement when I want to move over to OAuth2.

Finally, because the OpenEats code references a lot of different snippets of authentication, and these made no sense to me at the beginning of the project, I needed to delve into the Django documentation to learn more about its authentication mechanisms.  Even more to the point, I needed to learn how the code in front of me worked, so I had a clear stopping point when researching documentation.  Again, if this were green field, I either would have copied and pasted code I don't quite understand, or attempted to read as much documentation as possible in order to ensure that I wasn't missing out on some valuable detail.

So, to recap, here's what I got out of not simply writing an authentication app from scratch:

• I was able to leverage someone else's code to skip writing functionality that's generally considered tedious.
• I was able to delve into other code on github to better understand my own project (and, as we've been told time and time again, it's good to read others' code and get familiar with github projects).
• I had a ready definition of requirements for this portion of my project.
• I was able to delve somewhat deep into the authentication documentation while making sure I didn't go too deep that I couldn't come up for air.
• I found a lead for a possible future feature on my site.

Not too shabby for something that's generally considered maintenance programming.