Django 1.8 Tutorial - 5.1 Alternative Authentication (Make Your Own)

I was hoping to get into Allauth, or maybe that and some more UX tweaks, but ended up hitting some walls. We're trying to implement an authenticator that works with an external service, but it's more complex than expected. (I won't be posting it here.)

To get to the point where I could even write parts of the authenticator, I needed to teach myself how to write authenticators. So, here are two authenticators. Both are a little odd, but I think the code is short enough that it won't be confusing.

Django Edge

Edge 2 looks nice. I'm kind of surprised I haven't heard of it before.

Also, while I'm keying up this tutorial series, it's dawning on me that it would be good to state that I'm aware that the "in" thing is moving away from apps with templates, and toward REST and real-time. I am learning Django because I started out with Django REST Framework - and the DRF material didn't really cover the various authentication, authorization, and general programming issues.

Using List Comprehensions in Python to Look at Lists of Objects

List comprehensions are a difficult-to-learn feature of Python that seem unnecessarily terse, but that's because the examples aren't that practical. It's really a powerful tool.

I was using Tweepy to get some tweets from the Twitter API, and it was a LOT of data. You'd think a 140 character string isn't that big, but Twitter delivers a lot of metadata. It's around 7K of metadata per tweet.

So, I had 15 tweets in a list, or around 100K worth of __str__ representing dozens of objects. How do you slice that up?

You use dir() to explore the properties of the different objects.

Django 1.8 Tutorial - 5. Django Registration Redux

This text is a work in progress. I'm not even done with this part myself.

In doing some digging, I found out that the leading registration app, django-registration, was abandoned. Some time later, django-registration-redux picked up the ball and has maintained it. There's also another alternative django-allauth, which does registration and integrates with social sites.

The instructions for django-registration-redux are pretty good. Just read through them, and consider this tutorial just a slight gloss of what's covered, plus some specifics about our demo app.

Django 1.8 Tutorial - 4. Integrating the Default Login Screens, Adding HTML Email

So, I started implementing the Django provided user login screens yesterday and it was requiring a ton of reading to get the different parts working. It seems so simple, from the outside, but all the configuration options made it seem more difficult than it really is.

In the attached file, a few of the old configs and views have been deleted, but I'm not going to cover that here. Just do diffs between the contents of the attached tgz files to see the differences.

Create a file in your global templates, templates/registration/login.html:

{% extends "base.html" %}

Django 1.8 Tutorial - 3. Adding Account Logins

The previous article cleaned up the UI and made the comment system work more like a comment system, but it has a glaring flaw: you could choose to post as any user. LOLz.

This small modification adds login and logout features. It does it the raw way rather than use the built-in classes, or the django-registration-redux library. This is just a temporary feature, an example to learn authentication.

That said, it does something a little different from what seems to be provided by Django: the login is embedded right in the page, where the form would have been.

Django 1.8 Tutorial - 2. Polishing the App with Static Files, CSS, JS, etc.

The last article took several hours to write, so I'm going to take a break from writing and editing for a while. These tutorial posts will still happen, but they'll be harder to read.

The previous tutorial created a "comment system", and while it was a reasonable example of using ModelForms and generic View classes, it didn't look like a real comment system. This tutorial polishes the original and makes it more like a real web app.

Here's what it looks like:

It's still not "nice", but it's getting there.

Django 1.8 Tutorial - 1. A Minimal Application Made Using Generic Class Based Views

I'm not a Django expert. I'm a Django novice writing this document to help other novices. There are probably errors, and I welcome corrections.

This is an intermediate level document for people who know how to program, are fairly comfortable with Python, have done one or two Django tutorials, and know the Django file layout, but haven't really "gotten" Django or the generic View classes.

We will create a small web application with all the CRUD operations in around 120 lines. The tutorial emphasizes using the most generic names.

Sources are attached, below.

A Depressing Realization about Tutorials on the Web

I love the people who write tutorials (and fixes) on the web. I owe the vast community of writers so much, because they've taught me so much. It's the reason why I write these short notes, to be found by search engines, to help someone in a small jam.

Web API Design book I'm reading

This is a few years old, but it's a good overview of APIs and some good design patterns. There's a signup page.

Web API Design - Crafting Interfaces that Developers Love

It's good advice and easy reading, but there's what I consider an error in there. Over on page 26, they suggest that it's OK to make a request like "GET /foo/123?method=delete" that will delete the resource.

How to Add a REST API to an Existing Django Project

This is a note I wrote to myself about how to add Django REST Framwork to an existing project. It's in PDF format, for reading. I didn't have the time to create a real tutorial that builds up the API, or produce a really useful API. The intention is just to outline what parts get defined and how they work together.

Django error: Reverse for 'some-name' with arguments '(1,)' and keyword arguments '{}' not found. 0 pattern(s) tried: []

A nice feature of the URL matching rules is that even if you have named arguments in the url(), like so:

 url(r'^items/(?P<pk>[0-9]+)/$', ItemDetailView.as_view(), name='item_detail'),

the system will accept a positional parameter, like so:

{% url 'item_detail' item.id %}

I was thinking that it was going to be particular about named parameters, and I was searching for information about passing named parameters to url, but it wasn't necessary. Once again, misdirected by an error message.

Python Performance Rabbithole

I was looking for Django podcasts, and being that it's a community within a community found only a couple, and they were both not in operation anymore. I started to worry - was the project waning? It looked like updates and significant improvements were coming out at a fast pace.

Was Node taking over? I had to "research". Off to craigslist - nope. Node is popular, but there are still plenty of references to Django.... more actually. Then, I started to worry about whether nonblocking I/O was an issue - I know all the big, intepreted app servers like Django and ROR are slow - but really?

DIY Fixing ic! Berlin glasses if you sat or stepped on them

So, when I had some money, I blew it on these "designer" ic! Berlin frames. They look really high tech and cool, and they allegedly avoid damage by having these hinges that pop apart under pressure.

Here's a video of how it's supposed to work: https://www.youtube.com/watch?v=...

Here's another one: https://www.youtube.com/watch?v=...

Too bad the ones I got don't actually pop apart under pressure. I'll explain how to fix them in this blog post.

def fn(arg1,x=arg2,y=10,*args,**kwargs): GO PYTHON!

def fn(arg1,x=arg2,y=10,*args,**kwargs):

That's kind of ugly, but the design is elegant. With that declaration, the function supports positional arguments, required named arguments, optional arguments, an arbitrary number of additional unnamed arguments, and additional arbitrary named arguments.

It allows function calls to be simpler and more readable than they would be without this flexibility.

Syndicate content