Forem: Andrés Álvarez Iglesias

Using offline AI models for free in your Phyton scripts with Ollama

Andrés Álvarez Iglesias — Wed, 05 Mar 2025 06:13:14 +0000

First published on Substack: https://andresalvareziglesias.substack.com/p/using-offline-ai-models-for-free

The Ollama project allows us to donwload and use AI models for offline usage with our computer resources. This allows us to experiment with the AI in our Python projects without any cost, an testing a lot of models to find the ideal choice for our project. It's awesome.

Installation of Ollama

The installation of Ollama in a Linux device (for MacOS and Windows, check Ollama Github page) is very, very easy. Just write this command in a terminal:

curl -fsSL https://ollama.com/install.sh | sh

After a long wait, Ollama will be fully installed and configured.

Download a model

Once installed, we can download any model to our computer for offline usage. In the Ollama library page we can read the full list of available models.

For example, to download gemma2 with 2 billions of parameters, the command will be:

ollama pull gemma2:2b

The model will be downloaded to /usr/share/ollama/.ollama/models local folder, if you are curious (as I am).

Use the downloaded model in Python

Now, we can use the downloaded Gemma model as any other cloud model, like this:

from ollama import Client, ResponseError

try:
    client = Client(
        host='http://localhost:11434',
        headers={}
    )

    response = client.chat(
        model='gemma2:2b',
        messages=[{
            'role': 'user',
            'content': 'Describe why Ollama is useful',
        }]
    )

    print(response['message']['content'])

except ResponseError as e:
    print('Error:', e.error)

The program will output our requested answer. Wonderful!

A real example: check this article about Ollama... with Ollama

We can program a very simple article checker with Ollama and Python, like this

from ollama import Client, ResponseError

try:
    client = Client(
        host='http://localhost:11434',
        headers={}
    )

    prompt  = "I am an spanish writer that is learning how to "
    prompt += "write in english. Please, review if this article "
    prompt += "is well written. Thank you!\n\n"

    with open('article.md') as f:
        prompt += f.read()

    response = client.chat(
        model='gemma2:2b',
        messages=[{
            'role': 'user',
            'content': prompt,
        }]
    )

    print(response['message']['content'])

except ResponseError as e:
    print('Error:', e.error)

When executed, Gemma will give us a detailer analysis of this article, with advices for improvement.

Awesome! The possibilities are limitless!

A lot to learn, a lot of fun

Ollama allows us to test different models with our most precious data, without any privacy concern. Ollama allows to to save costs in the initial stages of development of an AI powered application.

And you? What kind of projects will you develop witn the help of Ollama?

Happy coding!

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

I'm Andrés, a full-stack software developer based in Palma, on a personal journey to improve my coding skills. I'm also a self-published fantasy writer with four published novels to my name. Feel free to ask me anything!

PWA and Django #4: Installing a PWA as a native application

Andrés Álvarez Iglesias — Tue, 21 Jan 2025 05:38:00 +0000

Welcome to the fourth entry on the Progressive Web Application with Django series. In this chapter we will learn how to install our webapp as a native application. Very useful and really easy.

Allowing native installation

With a small change to the source code, we can ask the user if they want to install our supercool webapp as a "native" app.

let beforeInstallPromptEvent = null;
let installed = false;

async function installPWA() {
   if (beforeInstallPromptEvent === null || installed) {
       return;
   }

   try {
       beforeInstallPromptEvent.prompt();

       const { outcome } = await beforeInstallPromptEvent.userChoice;
       if (outcome === 'accepted') {
           console.log("App install dialog accepted!");
           beforeInstallPromptEvent = null;
           installed = true;
       }

   } catch(e) {
       console.error(e);
   }
}

We can also listen to a couple of events to customize the responses and behavior of our webapp in every step of the process:

window.addEventListener('beforeinstallprompt', (e) => {
   beforeInstallPromptEvent = e;
});

window.addEventListener('appinstalled', () => {
   installed = true;
});

The user needs to fire the event, so an install button is a good place to call the new code:

When clicked, the user will see a browser dialog asking for the installation like this:

If accepted, the webapp will be registered on the operating system, with its own launcher icon:

Executing as a standalone app

Once installed, the web app will launch in its own window, providing a more integrated experience with styling based on the manifest (see previous chapters). Like this:

Note that you can customize the icon, the behavior of the webapp, colors, etc. in the PWA manifest. You can read more about this here:

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

PWA and Django #3: Online and offline resources in a PWA - Developing Progressive Web Applications with Django

Andrés Álvarez Iglesias — Wed, 27 Nov 2024 05:20:44 +0000

NOTE: First published in: https://andresalvareziglesias.substack.com/p/pwa-and-django-3-online-and-offline

Welcome to the third entry on the Progressive Web Application with Django series. In this chapter, we'll learn how to cache resources for our PWA to be able to use them offline, without an active internet connection.

Implementing Offline Functionality

In the previous chapters we defined an small PWA application with every required part: the manifest and the ServiceWorker. We learned how to register the PWA and developed a very simple interface with some images:

Now we will learn how to store data in the PWA cache and how to choose from where to load every image: from the internet or from the local cache.

To store one or more resources on the PWA cache we use a function like this on the ServiceWorker:

const CACHE_NAME = "DJANGO_PWA_TEST"
const MAIN_URL = "https://laboratorio.alvarezperello.com/djangopwa/";

self.addEventListener("install", (event) => {
   console.info("*** PWA event *** install", event);
   event.waitUntil(activateApp());
});

self.addEventListener("activate", (event) => {
   console.info("*** PWA event *** activate", event);
   event.waitUntil(activateApp());
});

async function activateApp() {
   // When a service worker is initially registered, pages won't use it
   // until they next load. The claim() method causes those pages to be
   // controlled immediately.
   console.log('Claiming control...');
   clients.claim().then((ev) => {
       console.log('...claimed!', ev);
   })

   manageCache();
}

self.addEventListener("sync", (event) => {
   console.info("*** PWA event *** sync", event);
   manageCache();
});

async function manageCache() {
   const cache = await caches.open(CACHE_NAME);
   if (!cache) {
       console.error("Error storing resources in cache!");
       return;
   }

   storeResourceInCache(cache, MAIN_URL+"static/demo/img/snake1.jpg");
   //storeResourceInCache(cache, MAIN_URL+"static/demo/img/snake2.png");
   //storeResourceInCache(cache, MAIN_URL+"static/demo/img/snake3.png");
}

async function storeResourceInCache(cache, element) {
   console.log("Storing resource in cache: "+element);
   cache.add(element).then(event => {
       console.info("Resource stored successfully! "+element);
   }).catch(event => {
       console.error("Error storing resource! "+element, event);
   });
}

Now, when we execute our PWA, we can read the cache messages in the developer console:

Registering service worker...
...register completed!
The service worker is active!

serviceworker.js: Claiming control...
serviceworker.js: Resource already in cache! static/demo/img/snake1.jpg

Our PWA cache is working!

Choosing from where to load each resource

When the PWA loads a resource, calls the fetch event, like this:

self.addEventListener("fetch", async (event) => {
   console.info("*** PWA event *** fetch", event);

   let url = event.request.url.toString();
   console.info("The PWA is loading a resource from: "+url);
});

We are in control of the request now, and can choose from where return the requested resource: from cache or from internet.

Here is an example of how to check if we have a resource cached and return it from cache. And, if not cached, request it from the Internet instead.

self.addEventListener("fetch", async (event) => {
   let url = event.request.url.toString();
   if (!url.includes("static/demo/img/snake")) {
       return false;
   }

   const cache = await caches.open(CACHE_NAME);
   if (!cache) {
       console.error("Error loading resources from cache!");
       return false;
   }

   let fetchResponsePromise = await cache.match(url).then(async (cachedResponse) => {
       if (cachedResponse && cachedResponse.ok) {
           console.warn("Loading from cache: "+url);
           return cachedResponse;

       } else {
           console.error("Error! the cache does not have this url! "+url);
           console.error(cache.keys());

           remoteFetchResponsePromise = await fetch(event).then(async (networkResponse) => {
               console.warn("Loading from internet: "+url);
               return networkResponse;
           });

           return remoteFetchResponsePromise;
       }
   });

   return (await fetchResponsePromise);
});

We can read the developer console to know from where every image has been loaded, like this:

In the next chapter

We now have a PWA. Now we will learn how to make an installable PWA, that will show as a native application in the operating system. That's one of the greatest functionalities of the PWAs: we can use them to create "almost native" applications using Django.

See you in the next chapter!

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

Performance of Python with and without GIL

Andrés Álvarez Iglesias — Wed, 23 Oct 2024 04:06:39 +0000

Since Python 3.13, the famous Python GIL is optional. This is a long requested functionality but, is the performance gain of threaded code real?

Let's test the performance of a threaded application with and without the GIL.

What is GIL?

GIL stands for Global Interpreter Lock, and is a mechanism only present in the standard Python implementation (CPython) that ensures the coherence and safety of Python internal and runtime objects. The GIL makes sure that only a single thread is executed at the same time, losing the benefits of a multicore environment.

The new versions make this security mechanism entirely optional, opening whole word of possible optimizations in multicore environments.

NOTE: this functionality is not yet available in the official releases of Python 3.14, but it will in the future.

Installing Python 3.14

Use these commands to install Python 3.14 in Ubuntu:

add-apt-repository ppa:deadsnakes/ppa
apt install python3.14-full python3.14-nogil

After the installation, we can test the installation with:

python3.14 --version

Great, now we have a working Python 3.14 installation. Now, we can create a virtual environment with:

python3.14 -m venv ~/venv314
source ~/venv314/bin/activate

Now we are ready to execute our tests!

Testing the same code with and without GIL

We have coded this application:

import time
import threading
import math

def test_function(num_thread):
    thread_start_time = time.time()
    print(F"Executing thread #{num_thread}...")
    math.factorial(250000)
    thread_execution_time = time.time() - thread_start_time
    print(F"...thread #{num_thread} finalized in {thread_execution_time} seconds")

print("Initializing thread test...")
start_time = time.time()

# Create multiple threads
threads = []
for num_thread in range(5):
    thread = threading.Thread(target=test_function, args=(num_thread,))
    thread.start()
    threads.append(thread)

# Wait for all threads to finish
for thread in threads:
    thread.join()

execution_time = time.time() - start_time
print(f"Finalized! Execution time: {execution_time} seconds")

Is a really simple application that spawns some threads and performs a CPU intensive task in each thread (a factorial). Now, we can execute the test code in each version, with and without GIL:

With GIL enabled:

PYTHON_GIL=1 python3.14-nogil test.py

Initializing thread test...

    Executing thread #0...
    Executing thread #1...
    Executing thread #2...
    ...thread #0 finalized in 1.6720194816589355 seconds
    ...thread #1 finalized in 1.6916308403015137 seconds
    Executing thread #3...
    ...thread #2 finalized in 1.8445136547088623 seconds
    Executing thread #4...
    ...thread #3 finalized in 0.9945917129516602 seconds
    ...thread #4 finalized in 1.0793228149414062 seconds

Finalized! Execution time: 4.599931955337524 seconds

And without GIL:

PYTHON_GIL=0 python3.14-nogil test.py

Initializing thread test...

    Executing thread #0...
    Executing thread #1...
    Executing thread #2...
    Executing thread #3...
    Executing thread #4...
    ...thread #0 finalized in 0.8833539485931396 seconds
    ...thread #2 finalized in 0.8942356109619141 seconds
    ...thread #3 finalized in 0.934593677520752 seconds
    ...thread #4 finalized in 1.2945129871368408 seconds
    ...thread #1 finalized in 1.2981431484222412 seconds

Finalized! Execution time: 1.3003475666046143 seconds

Wow! The performance gain is notable!

A brilliant future

The possibility of running Python code without GIL with the default Python interpreter opens a lot of optimization opportunities to the Python ecosystem. We can expect an improved Django, a faster FastAPI, more optimized ASGI or WSGI servers...

Let's wait for this future together!

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

PWA and Django #2: Components of a Progressive Web Application

Andrés Álvarez Iglesias — Tue, 24 Sep 2024 04:44:10 +0000

NOTE: First published on Substack: https://substack.com/@andresalvareziglesias

Welcome to the second entry on the Progressive Web Application with Django series. In this chapter we will learn the basic structure of a PWA and how to implement it in Django. Let’s go!

Components of a PWA

A PWA is composed of two main elements, the Service Worker and the manifest.

The Service Worker: is the script that handles the logic of the PWA. It manages all the events of the PWA lifecycle, and the offline behavior.
The manifest: in the manifest resides the PWA description for the browser, like the name, colors and icons. This is used to show installation dialogs to the user, and to register the PWA in the browser registry,

Scopes inside a PWA

One of the settings configured in the manifest is the PWA scope. That is: what resources are available (and controllable) by this PWA.

For example, if we register a PWA with the scope /my/great/pwa/, then:

We will be able to add to the offline cache an image like /my/great/pwa/images/one.png
…but not one like /non/pwa/images/two.png, because is outside the configured scope.

Choosing the right scope is important because affects a lot of aspects of our PWA, like:

Offline Functionality: By limiting the scope, you can ensure that only the necessary resources for your PWA are cached, optimizing offline performance.
Security: A well-defined scope helps prevent unauthorized access to sensitive data or resources.
Performance: A smaller scope can lead to faster load times, as the service worker doesn’t need to cache unnecessary files.

We can also use some HTTP headers to control the scope at server level, like the Header Set Service-Worker-allowed "/" header, but we will discuss them in the next chapters.

Implementing the PWA in Django

The basic implementation of a PWA does not require Django at all, because all the files are static javascript code and a JSON manifest. In the next chapters, we will use Django to add more power to our PWA, but le’ts start from the beginning.

The manifest file is a JSON file with the descriptor of the app and the reference to the icons and colors. There are a lot of web apps to help us with the creation of the icons, like “Manifest icons generator” (https://www.pwabuilder.com/imageGenerator).

A basic manifest file is:

{
   "name": "PWA with Django",
   "short_name": "PWA with Django",

   "display": "standalone",
   "background_color": "#ffffff",
   "theme_color": "#1b5e20",
   "orientation": "any",

   "start_url": "/",
   "scope": "/",

   "icons": [{
       "src": "/static/demo/img/icons/icon-48x48.png",
       "sizes": "48x48",
       "type": "image/png"
   }, {
       "src": "/static/demo/img/icons/icon-72x72.png",
       "sizes": "72x72",
       "type": "image/png"
   }, {
       "src": "/static/demo/img/icons/icon-96x96.png",
       "sizes": "96x96",
       "type": "image/png"
   }, {
       "src": "/static/demo/img/icons/icon-144x144.png",
       "sizes": "144x144",
       "type": "image/png"
   }, {
       "src": "/static/demo/img/icons/icon-192x192.png",
       "sizes": "192x192",
       "type": "image/png"
   }, {
       "src": "/static/demo/img/icons/icon-512x512.png",
       "sizes": "512x512",
       "type": "image/png"
   }]
}

After the manifest, we need to code the ServiceWorker, a javascript file responsible to handle the events of the PWA. The most basic events are “install” (when the user installs the PWA) and “activate” (when the PWA is loaded and executed).

self.addEventListener("install", (event) => {
   console.info("install", event);
});

self.addEventListener("activate", (event) => {
   console.info("activate", event);
});

When the man elements of the PWA are created (the manifest and the Service Worker), we need to instantiate then from the main view:

document.addEventListener('DOMContentLoaded', function() {
   initializeServiceWorker();
});

function resetLog() {
   document.getElementById("log").innerHTML = "";
}

function log(message) {
   console.log(message);
   document.getElementById("log").innerHTML += "<p>"+message+"</p>";
}

function error(message) {
   console.error(message);
   document.getElementById("log").innerHTML += "<p style='color: red;'>"+message+"</p>";
}

function initializeServiceWorker() {
   try {
       resetLog();

       log("Registering service worker...");
       navigator.serviceWorker.register('/serviceworker.js', {
           scope: '/',
           type: 'classic',
           updateViaCache: 'all'

       }).then(function(registration) {
           log("...register completed!");

           if (registration.installing) {
               error("The service worker is installing, reloading...");
               document.location.reload();
               return;

           } else if (registration.waiting) {
               const sw = registration.waiting;
               error("The service worker is waiting, reloading...");
               document.location.reload();
               return;

           } else if (registration.active) {
               log("The service worker is active!");

               if(!navigator.serviceWorker.controller){
                   error("Webpage controller is still none, reloading...");
                   document.location.reload();
               }
           }
       });

   } catch (e) {
       error(e.message);
   }
}

The scripts try to register the PWA when the view is loaded. If you have followed all the steps, the screen will show something like this:

We can use Chrome Web Developer tools to check if the PWA has been registered successfully. Open the Developers Tools and click on the “Application” tab. Then, select “Service Workers” or “Manifest” in the left sidebar to display our shiny PWA:

Great, isn’t it?

In the next chapter

We now have a PWA. Now we will learn how to make an installable PWA, that will show as a native application in the operating system. That’s one of the greatest functionalities of the PWAs: we can use them to create “almost native” applications using Django.

See you in the next chapter!

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I’m always open to learning something new!

About the author

I’m Andrés, a full-stack software developer based in Palma, on a personal journey to improve my coding skills. I’m also a self-published fantasy writer with four published novels to my name. Feel free to ask me anything!

PWA and Django #1: What is a Progressive Web Application?

Andrés Álvarez Iglesias — Tue, 10 Sep 2024 04:45:43 +0000

Originally published on Substack: https://andresalvareziglesias.substack.com/p/pwa-and-django-1-what-is-a-web-application?r=1ymfiv

The current web applications are much more than web pages that show interactive info. Sometimes, they behave almost like native apps. And what kind of magic do they use to do that? This series of posts will answer that question...

What is a Progressive Web Application

I like the definition of PWA's at Mozilla Developer site (https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps):

A progressive web app (PWA) is an app that's built using web platform technologies, but that provides a user experience like that of a platform-specific app. Like a website, a PWA can run on multiple platforms and devices from a single codebase. Like a platform-specific app, it can be installed on the device, can operate while offline and in the background, and can integrate with the device and with other installed apps.

It's an hybrid between a native app and a webpage, thanks to the incredible capacities of the nowadays web browsers, like:

Embedded database
Offline workers
Desktop and mobile operating system integration
Etc.

In this series of posts, we will develop an offline and installable Progressive Web Application using our beloved Django, with the help of Google Project IDX.

Create the demo environment

Create a github repo:

Create a new app in IDX importing that repo:

Initialize the Django app from the IDX console:

python -m venv ~/.venv
source ~/.venv/bin/activate

mkdir src
cd src

echo "django" > requirements.txt
pip install --upgrade pip
pip install -r requirements.txt

django-admin startproject djangopwa

Do the initial migration and run the server:

python manage.py migrate
python manage.py runserver

Create IDX files to enable embedded preview, with the help of the project https://github.com/arifnd/nix-idx/, that compiles several IDX configurations:

cd ~/djangopwa 
wget https://raw.githubusercontent.com/arifnd/nix-idx/main/python/django/devserver.sh
cd ~/djangopwa/.idx
wget https://raw.githubusercontent.com/arifnd/nix-idx/main/python/django/dev.nix

NOTE: Edit the default dev.nix and devserver.sh as needed and restart IDX environment

Then, create demo app:

python manage.py startapp demo

Add an empty view:

from django.shortcuts import render

def index(request):
    context = {}
    return render(request, "index.html", context)

Create the routes to the new app:

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path("", include("demo.urls")),
    path('admin/', admin.site.urls),
]

And wait a few days until the next chapter!

About the list

Among the Python and Docker posts, I will also write about other related topics, like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

Speeding up Python code with C (and no extra libraries)

Andrés Álvarez Iglesias — Wed, 21 Aug 2024 04:37:31 +0000

NOTE: Originally posted in my Substack: https://open.substack.com/pub/andresalvareziglesias/p/speeding-up-python-code-with-c-and

Python is not the paradigm of speed, we all know this. But we can speed up some critical parts of our apps with the help of our good old friend C.

The Fibonacci sequence in plain Python

The Fibonacci sequence is a classic example used to teach software development. Is a series of numbers that starts with 0 and 1. Each subsequent number is the sum of the previous two. So, the sequence goes like this: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, ...

We can develop Fibonacci in python in this way:

import time

# Configure iterations
iterations = 30

# Define fibonacci in native python
def fibonacci(n):
  if n <= 1:
    return n
  else:
    return fibonacci(n-1) + fibonacci(n-2)

# Calculate in pure python
start_time = time.perf_counter()
print(f"Calculating {iterations} iterations of fibonacci...")
print(fibonacci(iterations))
end_time = time.perf_counter()
execution_time_ms = (end_time - start_time) * 1000
print(f"Execution time: {execution_time_ms:.2f} milliseconds")
print()

If we execute this pure Python (in a Google IDX virtual machine) version of Fibonacci we get:

10 iterations: 5.77 milliseconds
30 iterations: 984.36 milliseconds
50 iterations: (I have to cancel the process, too much time)

The Fibonacci sequence in C

We can develop the same sequence in plain C:

#include <stdio.h>

int fibonacci(int n) {
    if (n <= 1) {
        return n;
    } else {
        return fibonacci(n - 1) + fibonacci(n - 2);
    }
}

Compile the library with GCC:

gcc -o fibonacci.so -shared -fPIC -O2 fibonacci.c

Now, we have a native binary library with the fibonacci sequence function inside. We can embed this library inside a Python app with ctypes (the Python C types library, because Python itself is developed in C):

import time
from ctypes import c_double, c_int, CDLL

# Configure iterations
iterations = 30

# Import the C library
library = CDLL('./fibonacci.so')
fibonacciAsLibrary = library.fibonacci
fibonacciAsLibrary.restype = c_int

# Calculate as C library
start_time = time.perf_counter()
print(f"Calculating {iterations} iterations of fibonacci as C library...")
print(fibonacciAsLibrary(iterations))
end_time = time.perf_counter()
execution_time_ms = (end_time - start_time) * 1000
print(f"Execution time: {execution_time_ms:.2f} milliseconds")
print()

Now, if we execute this version on Fibonacci, we get:

10 iterations: 0.54 milliseconds
30 iterations: 6.92 millisecond
50 iterations: 82324.90 milliseconds

Better, isn’t?

Use cases for Python and C integration

We can use this kind of integration in a lot of apps and scenarios, like:

Speed up serializers and deserializers in our Django app
Speed up critical parts on a workflow
Low level interactions with the OS
Etc.

And you? How will you use this litle trick in your project? I woult love to hear your comments!

About the list

Among the Python and Docker posts, I will also write about other related topics (always tech and programming topics, I promise... with the fingers crossed), like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

Django AllAuth Chapter 5 - Extending Django AllAuth user model with custom fields

Andrés Álvarez Iglesias — Tue, 13 Aug 2024 04:45:51 +0000

NOTE: This article was initially posted on my Substack, at https://andresalvareziglesias.substack.com/

This is the last chapter of this Django AllAuth series of posts. In these five chapters we have discovered a little piece of wonder, a really helpful Django component to handle all our authentication needs. In this chapter we are going to learn how to extend the basic Django user model to add custom fields.

List of chapters

Chapter 1 - The All-in-one solution for Auth in Django
Chapter 2 - How to install and configure Django AllAuth
Chapter 3 - Social login with Django AllAuth
Chapter 4 - Customizing Django AllAuth UI
Chapter 5 - Extending Django AllAuth user model with custom fields ←This one!

Django user model

AllAuth uses the standard Django user model, plus some extra tables to handle social login and login tokens. In Django 5, the user model is located in the django.contrib.auth package, and has a bunch of predefined fields, as you can read in the official doc:

https://docs.djangoproject.com/en/5.0/ref/contrib/auth/

Sometimes, this is not enough for our project. Django allows you to create custom User tables and User managers, to handle the needs of every project.

We are going to create a custom User table and a custom UserManager to handle our login and register processes.

Creating a custom User table

Open models.py in our sample project an write a code like this:

class MyCustomUser(AbstractBaseUser):
   email = models.EmailField(unique=True)
   first_name = models.CharField(max_length=30, blank=True)
   last_name = models.CharField(max_length=30, blank=True)
   is_active = models.BooleanField(default=True)
   is_admin = models.BooleanField(default=False)
   timezone = models.CharField(max_length=30, default='UTC')
   is_custom = models.BooleanField(default=False)
   is_staff = models.BooleanField(default=False)
   created_at = models.DateTimeField(auto_now_add=True)
   updated_at = models.DateTimeField(auto_now=True)

   objects = MyCustomUserManager()
   USERNAME_FIELD = 'email'
   EMAIL_FIELD = 'email'

   def __str__(self):
       return self.email
   def has_perm(self, perm, obj=None):
       return True
   def has_module_perms(self, app_label):
       return True

   @property
   def is_utc(self):
       return self.timezone == 'UTC'

We can define a new User model extending from Django's AbstractBaseUser model. In this new model we can add all fields or custom properties that we need.

These lines are important:

   objects = MyCustomUserManager()
   USERNAME_FIELD = 'email'
   EMAIL_FIELD = 'email'

With these lines we are linking the user model with our custom UserManager, and we are also defining the field acting as a unique "username".

Remember to register the new model in admin.py to manage it from the Django admin tool.

from django.contrib import admin
from .models import MyCustomUser

admin.site.register(MyCustomUser)

Creating a custom User manager

Open again models.py in our sample project (or generate another file for the custom UserManager if you want) an write a code like this:

class MyCustomUserManager(BaseUserManager):

   def create_user(self, email, password=None):
       if not email:
           raise ValueError('Users must have an email address')

       user = self.model(
           email=self.normalize_email(email),
       )

       user.set_password(password)

       user.save(using=self._db)
       return user

   def create_superuser(self, email, password):
       user = self.create_user(
           email=email,
           password=password,
       )

       user.is_admin = True
       user.is_staff = True

       user.save(using=self._db)
       return user

In this example we are extending BaseUserManager to create our custom UserManager. It creates our new users, and fills the custom fields as we expect.

We defined before the UserManager for our custom User model, so Django knows what class to use during new user creation.

Using the custom User manager and model

In the settings file of our project we can set the current user model for our project with:

# Set custom user model as the active one
AUTH_USER_MODEL = 'demo.MyCustomUser'

# Configure AllAuth username related management, because we are 
# using the e-mail as username. See:
# https://docs.allauth.org/en/latest/account/advanced.html
ACCOUNT_AUTHENTICATION_METHOD = 'email'
ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_UNIQUE_EMAIL = True
ACCOUNT_USERNAME_REQUIRED = False
ACCOUNT_USER_MODEL_USERNAME_FIELD = None

With just this small change (and the required DB migration, as usual), we can start to create users with AllAuth signup views to see our shiny custom UserManager and its model in action. Quick and easy.

We are also disabling the AllAuth username related management, because we are using the e-mail as username in this example.

And that's the end... or not?

We have reached the last chapter on this AllAuth series. AllAuth is a wonderful library to handle the authentication in our apps, and makes it especially easy to work with social logins, thanks to its large list of predefined integrations.

This is the last chapter of the series, but I will revisit AllAuth in future posts. Thanks for reading and happy coding!

About the list

Among the Python and Docker posts, I will also write about other related topics (always tech and programming topics, I promise... with the fingers crossed), like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

Django AllAuth Chapter 4 - Customizing Django AllAuth UI

Andrés Álvarez Iglesias — Tue, 30 Jul 2024 05:25:16 +0000

In the previous chapters we have implemented a basic login and a social login with the help of AllAuth, using the default (and ugly) user interface. Now is the time of adding a touch of color to our little app.

List of chapters

Chapter 1 - The All-in-one solution for Auth in Django
Chapter 2 - How to install and configure Django AllAuth
Chapter 3 - Social login with Django AllAuth
Chapter 4 - Customizing Django AllAuth UI ←This one!
Chapter 5 - Extending Django AllAuth user model with custom fields

Templates in AllAuth

All default views in AllAuth are intentionally plain and unstyled. They are prepared to be customized on every app. In the AllAuth GIT page (https://github.com/pennersr/django-allauth) we can obtain a full list of the used templates.

There are four groups:

Basic authentication templates: login, logout, registering, password recovery, etc
Social authentication templates: social login workflow
Account management: user profile, user actions, etc
Other: mail templates, common snippets, etc.

To start with our customization, we will download the GIT repo and copy some AllAuth templates to our template directory:

Allauth
account
socialaccount

You can copy all of them if you want to play a bit more, of course :)

Customizing base layout

The file "allauth/layouts/base.html" contains the basic layout of all AllAuth pages, so we will start customizing it, using the fantastic MaterializeCSS library (https://materializeweb.com/getting-started.html). Simply, add the MaterializeCSS required inclusions, a topbar and a container card. Add other card for the messages and move the menu to the navbar:

{% load i18n %}
<!DOCTYPE html>
<html>

<head>
   <meta http-equiv="X-UA-Compatible" content="IE=edge">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">

   <title>
       {% block head_title %}
       {% endblock head_title %}
   </title>

   <!-- Compiled and minified CSS -->

   <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@materializecss/materialize@2.1.0/dist/css/materialize.min.css">

   {% block extra_head %}
   {% endblock extra_head %}
</head>

<body>

   <header>
       <nav>
           <div class="nav-wrapper indigo darken-4 white-text">

               <a href="#" class="brand-logo">AllAuth test</a>

               <ul id="nav-mobile" class="right hide-on-med-and-down">
               {% if user.is_authenticated %}
                   {% url 'account_email' as email_url %}
                   {% if email_url %}
                       <li>
                           <a href="{{ email_url }}">{% trans "Change Email" %}</a>
                       </li>
                   {% endif %}
                   {% url 'account_change_password' as change_password_url %}
                   {% if change_password_url %}
                       <li>
                           <a href="{{ change_password_url }}">{% trans "Change Password" %}</a>
                       </li>
                   {% endif %}
                   {% url 'mfa_index' as mfa_url %}
                   {% if mfa_url %}
                       <li>
                           <a href="{{ mfa_url }}">{% trans "Two-Factor Authentication" %}</a>
                       </li>
                   {% endif %}
                   {% url 'usersessions_list' as usersessions_list_url %}
                   {% if usersessions_list_url %}
                       <li>
                           <a href="{{ usersessions_list_url }}">{% trans "Sessions" %}</a>
                       </li>
                   {% endif %}
                   {% url 'account_logout' as logout_url %}
                   {% if logout_url %}
                       <li>
                           <a href="{{ logout_url }}">{% trans "Sign Out" %}</a>
                       </li>
                   {% endif %}
               {% else %}
                   {% url 'account_login' as login_url %}
                   {% if login_url %}
                       <li>
                           <a href="{{ login_url }}">{% trans "Sign In" %}</a>
                       </li>
                   {% endif %}
                   {% url 'account_signup' as signup_url %}
                   {% if signup_url %}
                       <li>
                           <a href="{{ signup_url }}">{% trans "Sign Up" %}</a>
                       </li>
                   {% endif %}
               {% endif %}

               </ul>
           </div>
       </nav>
   </header>

   <main>
       <div class="container">

       {% block body %}

           {% if messages %}
               <div class="row"><div class="col s12">
                   <div class="card yellow black-text">
                       <div class="card-content">
                           <span class="card-title">{% trans "Messages:" %}</span>
                           <ul>
                               {% for message in messages %}<li>{{ message }}</li>{% endfor %}
                           </ul>
                       </div>
                   </div>
               </div></div>
           {% endif %}

           <div class="row"><div class="section col s12">
               <div class="card white">
                   <div class="card-content">
                       {% block content %}
                       {% endblock content %}
                   </div>
               </div>
           </div></div>

       {% endblock body %}

       </div>
   </main>

   <!-- Compiled and minified JavaScript -->

   <script src="https://cdn.jsdelivr.net/npm/@materializecss/materialize@2.1.0/dist/js/materialize.min.js"></script>

   {% block extra_body %}
   {% endblock extra_body %}

</body>

</html>

Before the UI update:

After the UI update:

A wonderful look change with just a few lines!

Customizing the login form

We still need to change individual components. The login form is located in the file "account/login.html". We will update the components to accommodate them to MaterializeCSS expected layout:

{% extends "account/base_entrance.html" %}
{% load i18n allauth account %}

{% block head_title %}
   {% trans "Sign In" %}
{% endblock head_title %}

{% block content %}

   <span class="card-title">{% trans "Sign In" %}</span>

   {% if not SOCIALACCOUNT_ONLY %}

       {% setvar link %}
           <a href="{{ signup_url }}">
           {% endsetvar %}
           {% setvar end_link %}
           </a>
       {% endsetvar %}

       <div class="row"><div class="col s12">
           {% blocktranslate %}
               If you have not created an account yet, then please {{ link }}sign up{{ end_link }} first.
           {% endblocktranslate %}
       </div></div><br/>

       {% url 'account_login' as login_url %}
       {% element form form=form method="post" action=login_url tags="entrance,login" %}
           {% slot body %}
               {% csrf_token %}
               {% element fields form=form unlabeled=True %}
               {% endelement %}
               {{ redirect_field }}
           {% endslot %}

           {% slot actions %}
               <input class="btn indigo darken-2 white-text" type="submit" tags="prominent,login" value="{% trans "Sign In" %}" />
               <br/><br/><br/>
           {% endslot %}

       {% endelement %}
       <br/>

   {% endif %}

   {% if LOGIN_BY_CODE_ENABLED %}
       {% element h2 %}
           {% element button href=request_login_code_url tags="prominent,login,secondary" %}
               {% trans "Mail me a sign-in code" %}
           {% endelement %}
       {% endelement %}
   {% endif %}

   {% if SOCIALACCOUNT_ENABLED %}
       {% include "socialaccount/snippets/login.html" with page_layout="entrance" %}
   {% endif %}

{% endblock content %}

To update the "social" part of the login form, we need to update also the "socialaccount/snippets/login.html" file:

{% load i18n allauth  socialaccount %}
{% get_providers as socialaccount_providers %}

{% if socialaccount_providers %}

   {% if not SOCIALACCOUNT_ONLY %}
       <span class="card-title">{% trans "Or use a third-party" %}</span>
   {% endif %}

   {% include "socialaccount/snippets/provider_list.html" with process="login" %}
   {% include "socialaccount/snippets/login_extra.html" %}

{% endif %}

In AllAuth, each element has it's own template for easy customization, we can also add some classes to forms, fields and buttons to fully customize each shown element.

The final result:

Better, isn’t?

Endless customization possibilities

All internal views of AllAuth have their own customizable HTML. All individual HTML components have it's own template. With this clever system, it's easy to customize each tiny part of AllAuth user interface.

The possibilities are endless!

About the list

Among the Python and Docker posts, I will also write about other related topics (always tech and programming topics, I promise... with the fingers crossed), like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

Django AllAuth Chapter 3 - Social login with Django AllAuth

Andrés Álvarez Iglesias — Fri, 19 Jul 2024 04:22:08 +0000

Django AllAuth also simplifies the integration with a lot -really, A LOT- of third party authentication platforms, like Google, Facebook, Microsoft, Github, etc. Let's see how to integrate Google login in our demo application.

List of chapters

Chapter 1 - The All-in-one solution for Auth in Django
Chapter 2 - How to install and configure Django AllAuth
Chapter 3 - Social login with Django AllAuth ←This one!
Chapter 4 - Customizing Django AllAuth UI
Chapter 5 - Extending Django AllAuth user model with custom fields

Configuring an OAuth application on Google

First, we need to configure an OAuth (Open Authorization) application in Google cloud servers. All the process is explained in detail in https://developers.google.com/identity/protocols/oauth2, and involves the following steps:

Log into you Google Developer account at https://console.cloud.google.com/apis/dashboard
Create a new application or select an existent one
Select "credentials" on the sidebar and create a new "OAuth client ID" selecting "Web application" as it type. Fill with the correct URLs (the return url "/accounts/google/login/callback/" is an internal AllAuth managed URL) and annotate the client ID and secret.

Then, select "OAuth consent screen on the sidebar and configure the app name as shown to the users, and select a logo. Also, configure the e-mails allowed for testing in the development phase.

With these simple steps, after a while our OAuth Google Authentication will be ready to be integrated in our AllAuth application.

Integrating the Google authentication with AllAuth

Now, open the Django app main settings file (settings.py) and add a new block, writing the ClientID and secret obtained from Google before:

# Provider specific settings
SOCIALACCOUNT_PROVIDERS = {
   'google': {
       'APP': {
           'client_id': 'xxxxxxxxxxxx.apps.googleusercontent.com',
           'secret': 'GOCSPX-xxxxxxxxxxxxxxxxxxxxxxxx',
           'key': ''
       }
   }
}

Also, add the AllAuth social modules to active apps if not already configured:

INSTALLED_APPS = [
   (...)

   'allauth',
   'allauth.account',
   'allauth.socialaccount',
   'allauth.socialaccount.providers.google',

   'demo'
]

And add a bunch of extra settings to configure the behavior of AllAuth at the end of the settings file:

# AllAuth settings
SITE_ID = 1         

ACCOUNT_LOGIN_REDIRECT_URL ="/"
ACCOUNT_LOGOUT_REDIRECT_URL ="/"

ACCOUNT_EMAIL_REQUIRED = True
ACCOUNT_EMAIL_VERIFICATION = False
ACCOUNT_PASSWORD_MIN_LENGTH = 8
ACCOUNT_DEFAULT_HTTP_PROTOCOL='https'
ACCOUNT_LOGOUT_ON_GET = True

SOCIALACCOUNT_EMAIL_REQUIRED = True
SOCIALACCOUNT_EMAIL_VERIFICATION = False
SOCIALACCOUNT_EMAIL_AUTHENTICATION = True
SOCIALACCOUNT_LOGIN_ON_GET=True
SOCIALACCOUNT_AUTO_SIGNUP = True

And that's all! Awesome!

Testing the social login

Open the preview of the app on IDX and navigate to /accounts/login/:

Click on the "Google" social login, we will be redirected to the well known Google login page, yay! Select your google account and click on "login" button to finalize the social login.

Google will redirect the user to the internal AllAuth login page that will finalize the process and redirect the user to the internal protected page.

The process is simple and works great, but the default interface is intentionally simple and ugly. In the next chapter we will learn how to customize it.

About the list

Among the Python and Docker posts, I will also write about other related topics (always tech and programming topics, I promise... with the fingers crossed), like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

Django AllAuth Chapter 2 - How to install and configure Django AllAuth

Andrés Álvarez Iglesias — Thu, 11 Jul 2024 04:38:03 +0000

In this chapter we'll explore the basics of the AllAuth extension: from the installation to a basic usage for a login/password based access to our Django app. Let's go!

(NOTE: First published in my Substack list: https://andresalvareziglesias.substack.com/)

List of chapters

Chapter 1 - The All-in-one solution for Auth in Django
Chapter 2 - How to install and configure Django AllAuth ←This one!
Chapter 3 - Social login with Django AllAuth
Chapter 4 - Customizing Django AllAuth UI
Chapter 5 - Extending Django AllAuth user model with custom fields

Installation of AllAuth

As any other Django extension, AllAuth installation has two parts: install the python dependencies and configure the Django app settings file. To make things more fun, we will use (and learn) Google Project IDX, a wonderful cloud IDE and development platform.

First, log into IDX and create a new Django based project:

Once created, we will have a fully working Django app, so move on!

The installation of AllAuth itself is simple: just install the django-allauth python package. Project IDX (and ourselves, in case of manual project creation) creates a requirements.txt file, so let's use it:

Add "django-allauth" to dependencies.txt. You can also add "django-allauth[socialaccount]", used in the next chapter for social login
Open the IDX terminal and navigate to dependencies.txt parent folder
Load the virtual environment created with out project by IDX: source ~/allauth-test/.venv/bin/activate
Execute: pip install -r requirements.txt

Now, we need to make some changes to the main Django app settings file. Open settings.py and locate the TEMPLATES setting. Add the AllAuth required processor:

TEMPLATES = [
   {
       'BACKEND': 'django.template.backends.django.DjangoTemplates',
       'DIRS': [],
       'APP_DIRS': True,
       'OPTIONS': {
           'context_processors': [
               'django.template.context_processors.debug',
               'django.template.context_processors.request',
               'django.contrib.auth.context_processors.auth',
               'django.contrib.messages.context_processors.messages',

               # This one                
               'django.template.context_processors.request',
           ],
       },
   },
]

Then, locate the AUTHENTICATION_BACKENDS setting and add the AllAuth backend. If not present, add it now:

AUTHENTICATION_BACKENDS = [
   # Needed to login by user in admin, regardless of `allauth`
   'django.contrib.auth.backends.ModelBackend',

   # This one
   'allauth.account.auth_backends.AuthenticationBackend',
]

Next, add AllAuth to installed apps as any other Django extension. You can also add the social login extensions here, used in the next chapter:

INSTALLED_APPS = [
   'django.contrib.admin',
   'django.contrib.auth',
   'django.contrib.contenttypes',
   'django.contrib.sessions',
   'django.contrib.messages',
   'django.contrib.staticfiles',

   # Add these
   'allauth',
   'allauth.account',
   'allauth.socialaccount',
   'allauth.socialaccount.providers.google',
]

The last modification of the settings file is the required middleware. Locate the MIDDLEWARE section and add the AllAuth middleware at the end:

MIDDLEWARE = [
   'django.middleware.security.SecurityMiddleware',
   'django.contrib.sessions.middleware.SessionMiddleware',
   'django.middleware.common.CommonMiddleware',
   'django.middleware.csrf.CsrfViewMiddleware',
   'django.contrib.auth.middleware.AuthenticationMiddleware',
   'django.contrib.messages.middleware.MessageMiddleware',
   'django.middleware.clickjacking.XFrameOptionsMiddleware',

   # This one
   "allauth.account.middleware.AccountMiddleware",
]

AllAuth has it own views, templates and databases, so we need to perform some extra actions. The first action is to define the URLs for AllAuth views. Open the main urls.py and add them:

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
   path('admin/', admin.site.urls),
   path('accounts/', include('allauth.urls')),
]

Now, the code modifications are completed, but we need to create AllAuth required tables. Use the Django migration tool from the IDX terminal, navigating to manage.py location and executing:

python3 manage.py migrate

We also need an administrator to test the login (and to create users). Create it now:

python3 manage.py createsuperuser

Testing AllAuth installation

Now, we have a fully working AllAuth installation. To test the authentication methods, create a demo app with manage.py:

python3 manage.py startapp demo

INSTALLED_APPS = [
   (...)

   'allauth',
   'allauth.account',
   'allauth.socialaccount',
   'allauth.socialaccount.providers.google',

   # This one
   'demo'
]

And map it to main urls.py file:

urlpatterns = [
   path('', include('demo.urls')),
   path('admin/', admin.site.urls),
   path('accounts/', include('allauth.urls')),
]

Then, create a simple view in our new demo app:

from django.shortcuts import render
from django.http import HttpResponse

def indexView(request):
   if request.user.is_authenticated:
      return HttpResponse("""
         <span style='color: green;'>Logged in</span>
         """)
   else:
      return HttpResponse("""
         <span style='color: red;'>Not logged in</span>
         """)

And map it to demo's urls.py:

from django.contrib import admin
from django.urls import path, include
from demo.views import indexView

urlpatterns = [
   path('', indexView, name='indexView'),

   # Override default postlogin action with our view
   path('accounts/profile/', indexView, name='profileOverridenView'),
]

And now, load the page in IDX’s viewer:

We can use now AllAuth views to perform authentication. For example, use /accounts/login endpoint to perform a login with the previously created user:

And then, we will receive the expected login page:

You can also use other useful AllAuth views, like:

Signup: /accounts/signup/
Login: /accounts/login/
Logout: /accounts/logout/
Change password: /accounts/password/change/

Simple and easy!

About the list

Among the Python and Docker posts, I will also write about other related topics (always tech and programming topics, I promise... with the fingers crossed), like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!

About the author

Django AllAuth Chapter 1 - The All-in-one solution for Auth in Django

Andrés Álvarez Iglesias — Wed, 26 Jun 2024 04:52:53 +0000

After some experimentation in previous articles, now we will build some useful apps with Django. And one of the most important aspects of any web app is the user authentication. Django has a pretty useful authentication mechanism, but in this series of articles we will explore a full authentication package: Django AllAuth.

List of chapters

Chapter 1 - The All-in-one solution for Auth in Django ←This one!
Chapter 2 - How to install and configure Django AllAuth
Chapter 3 - Social login with Django AllAuth
Chapter 4 - Customizing Django AllAuth UI
Chapter 5 - Extending Django AllAuth user model with custom fields

The All-in-one solution for Auth in Django

Django AllAuth defines itself as a "Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication". And is a pretty good definition.

You can read more about Django AllAuth on:

It's home page
In the official documentation (very well written and structured)
In it's GitHub project page

A very, very interesting project that we will unleash in the core of our Django app in the following chapters.

What's next

In this series of articles we will learn how to install and configure AllAuth to have a fully working authentication in our Django App. And later, we will customize the default experience of AllAuth components.

Django AllAuth includes:

Login
Signup
Logout
Password Management
Password Reset
Emails Management
Email Verification

All of these with a rate limit mechanism to prevent brute force attacks. Pretty good, isn't it?

At the end of the series we will know how to:

Allow users to register in our site, through user/password/email and with social accounts
Allow users to login in our site, through user/password/email and with social accounts
Display user profile and allow change and recover it password

Do you want to come with us on this journey?

About the list

Among the Python and Docker posts, I will also write about other related topics (always tech and programming topics, I promise... with the fingers crossed), like:

Software architecture
Programming environments
Linux operating system
Etc.

If you found some interesting technology, programming language or whatever, please, let me know! I'm always open to learning something new!