A lot of django!

Part two of six in the 2017 edition of our annual PyCon Must-See Series, highlighting the talks our staff especially loved at PyCon. While there were many great talks, this is our team's shortlist.

One of the talks that I considered a must-see was a keynote presentation by Instagram employees Lisa Guo and Hui Ding about upgrading Python and Django.

This is something that many businesses know they "should" do, but think is too impractical "right now". Instagram performed an upgrade without any downtime and without slowing down the pipeline of new features. Caktus carries out Django upgrades as part of our managed hosting and upgrade protection services, so this talk was especially relevant to what we do as a company.

In your Django template put something like this:

 <ul>
 


 {% for object in object_list %}
 


   <li>{{ forloop.counter0|add:page_obj.start_index }}. {{ object }}</li>
 


 {% endfor %}
 


 </ul>
 

Where:

object_list - is a list of objects produced by pagination;

page_obj - is a page object produced by pagination

page_obj ...

Read now

This is an interview I took from Estonian Django developer Rivo Laks about Docker. Recorded in DjangoCon EU 2017, Florence, Italy.

https://djangodeployment.com/wp-content/uploads/2017/05/rivo.mp3

 

A: Hello everyone, this is Antonis from djangodeployment.com. The date is 7 April 2017 and I am in Florence, Italy, at the European Django conference. I’m sitting with Rivo Laks, who is a developer from Estonia. He has a company called Thorgate, and we are going to be talking about Docker and similar things, mostly about deployment. Hello Rivo, how do you like the conference?

R: Hello Antonis. I like it a lot and I think it’s my fifth DjangoCon now, so it’s been a pleasant experience throught the years.

A: That’s very interesting because it’s actually my first Django conference. So what do you think it is that brings you here?

R: I guess it’s the people, most importantly; and also the fact that this is a good place to keep you up to date with everything that is going on in the Django world.

A: Would you like to tell me some examples of Django applications that your company makes?

R: Well, it usually begins with some sort of business problem. One recent example is a company that manufactures pipes, and they needed a better way of getting an overview and keeping an overview of their production process and production queues, so we helped them with that by creating a Django application that basically contains the schedule for the production, so that they can add new pipes there from their existing bookkeeping software, then do quality assurance as well as use it in the future for actual monitoring of the production.

A: You made an interesting presentation a few days ago about how you use Docker to deploy your Django apps. So the question, first of all, is if this is something you have been doing for a long time, and I would especially like to know what problem Docker is solving for you.

R: We started looking into Docker because we had some dependency isolation issues, because for more recent projects we wanted to use more recent versions of Python and PostgreSQL, and at the same time we had, in the same server, older projects, running on older versions of Python, which we didn’t feel like upgrading at that time. We hoped Docker would help us keep these requirements and different versions of Python separate for each project. I think it succeeded in that, because we are now able to accomplish that and we have been using Docker in test and production servers for something like six months now, perhaps slightly less. It’s a quite recent development, but all the projects we are starting today are based on Docker.

A: I understand that you mostly deploy on single server. So you may have a virtual server and you deploy some Django applications in there. When this problem arose, and you had made some applications that use newer versions of PostgreSQL and Python, why didn’t you just create another virtual server perhaps, and you needed to use Docker to isolate things on the same virtual server?

R: We do use quite a low number of servers and put multiple projects on a single server because the projects themselves are often quite small and they don’t require a full server and so on one hand it is financially more efficient to keep multiple projects on a single server, and on the other hand it’s also more efficient for us to not have to maintain multiple servers, because we only have to monitor, configure backups and everything else for a low number of machines.

A: There is a lot of hype about Docker; we were discussing this yesterday. It’s a relatively new technology, it’s changing a lot, and it seems like it’s the new fashion that is going to solve, somehow, magically, all your problems, like XML was 20 years ago—I can’t remember any more recent example though I’m certain there is. When would you advise someone NOT to use Docker?

R: I definitely agree with you about the hype, there’s lots of hype going around, and it makes it a bit difficult to find good and objective information. When would I advise to not use Docker? I think that if you have a project that’s already running, that’s perhaps a bit on the bigger side, and that you’re not that actively developing any more, then there’s probably no point in moving to Docker. Perhaps you don’t need Docker in some cases. For us there was a very clear need or desire of what we wanted to accomplish with Docker, so if you don’t have that need, if you are looking at the advantages Docker might give you, and decide that these advantages are not really something that are a problem for you, then I guess you can just skip on it.

A: Thank you very much Rivo, and I hope to see you again next year.

R: Thank you for having me, and likewise.

 

Related information:

• Rivo Laks
• Thorgate
• Slides from Rivo’s presentation

Did you like this post?

Interview
© 2017 Antonis Christofides and Rivo Laks.
The interview is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.

Photo by Bartek Pawlik
© 2017 DjangoCon Europe 2017
Original photo

The post Interview with Rivo Laks about Docker appeared first on Django deployment.

Our last post was about Authentication and Permissions and we covered the available methods of authentication in Django REST Framework. In that post, we learned how to use the built in Token based authentication in DRF. In this post, we will learn more about JSON Web Tokens aka JWT and we will see if JWT can be a better authentication mechanism for securing our REST APIs.

Understanding JSON Web Tokens (JWTs)

We have actually written a detailed blog post about JSON Web Tokens earlier. In case you have missed it, you probably should read it first. We have also described how to use JWT with Flask – reading that one might also help better understand how things work. And of course, we will briefly cover the idea of JWT in this post as well.

If we want to put it simply – you take some data in JSON format, you hash it with a secret and you get a string that you use as a token. You (your web app actually) pass this token to the user when s/he logs in. The user takes the token and on subsequent requests, passes it back in the “Authorization” header. The web app now takes this token back, “decodes” it back to the original JSON payload. It can now read the stored data (identity of the user, token expiry and other data which was embedded in the JSON). While decoding, the same secret is used, so third party attackers can’t just forge a JWT. We would want our token to be small in size, so the JSON payload is usually intentionally kept small. And of course, it should not contain any sensitive information like user password.

JWT vs DRF’s Token Based Authentication

So in our last blog post, we saw Django REST Framework includes a token based authentication system which can generate a token for the user. That works fine, right? Why would we want to switch to JSON Web Tokens instead of that?

Let’s first see how DRF generates the tokens:

    def generate_key(self):
        return binascii.hexlify(os.urandom(20)).decode()

It’s just random. The token generated can not be anyway related to the user that it belongs to. So how does it associate a token with an user? It stores the token and a reference to the user in a table in database. Here comes the first point – while using DRF’s token based auth, we need to query database on every request (unless of course we have cached that token which). But what if we have multiple application servers? Now we need all our application servers to connect to the same database or same cache server. How will that scale when the project gets really really big? What if we want to provide single sign on across multiple services? We will need to maintain a central auth service where other services request to verify a token. Can JWT simplify these for us?

JWT is just an encoded (read – hashed / signed) JSON data. As long as any webservice has access to the secret used in signing the data, it can also decode and read the embedded data. It doesn’t need any database calls. You can generate the token from one service and other services can read and verify it just fine. It’s more efficient and simply scales better.

JWT in Django REST Framework

DRF does not directly support JWTs out of the box. But there’s an excellent package that adds support for it. Let’s see how easily we can integrate JWT in our REST APIs.

Install and Configure

Let’s first install the package using pip –

pip install djangorestframework-jwt

That should install the package. Now we need to add rest_framework_jwt.authentication.JSONWebTokenAuthentication to the default authentication classes in REST Framework settings.

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_jwt.authentication.JSONWebTokenAuthentication',
        'rest_framework.authentication.BasicAuthentication',
        'rest_framework.authentication.SessionAuthentication',
        'rest_framework.authentication.TokenAuthentication',
    )
}

We added it to the top of the list. Next, we just have to add it’s built in view to our urlpatterns.

from rest_framework_jwt.views import obtain_jwt_token

urlpatterns = router.urls + [
    url(r'^jwt-auth/', obtain_jwt_token),
]

Obtain a Token

The obtain_jwt_token view will check the user credentials and provide a JWT if everything goes alright. Let’s try it.

$ curl --request POST \
  --url http://localhost:8000/api/jwt-auth/ \
  --header 'content-type: application/json' \
  --data '{"username": "test_user", "password": "awesomepwd"}'

{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoyLCJlbWFpbCI6IiIsInVzZXJuYW1lIjoidGVzdF91c2VyIiwiZXhwIjoxNDk1OTkyOTg2fQ.sWSzdiBNNcXDqhcdcjWKjwpPsVV7tCIie-uit_Yz7W0"}

Awesome, everything worked just fine. We have got our token too. What do we do next? We use this token to access a secured resource.

Using the obtained JWT

We need to pass the token in the form of JWT <token> as the value of the Authorization header. Here’s a sample curl request:

$ curl -H "Content-Type: application/json" -H "Authorization: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoyLCJlbWFpbCI6IiIsInVzZXJuYW1lIjoidGVzdF91c2VyIiwiZXhwIjoxNDk1OTkyOTg2fQ.sWSzdiBNNcXDqhcdcjWKjwpPsVV7tCIie-uit_Yz7W0" -X GET  http://localhost:8000/api/subscribers/

[{"id":1,"name":"Abu Ashraf Masnun","age":29,"email":"masnun@polyglot.ninja"},{"id":2,"name":"Abu Ashraf Masnun","age":29,"email":"masnun@polyglot.ninja"},{"id":3,"name":"Abu Ashraf Masnun","age":29,"email":"masnun@polyglot.ninja"},{"id":4,"name":"Abu Ashraf Masnun","age":29,"email":"masnun@polyglot.ninja"}]

So our token worked fine! Cool!

Where to go next?

Now that you have seen how simple and easy it is to add JSON Web Token based authentication to Django REST Framework, you probably should dive deeper into the package documentation. Specially these topics might be interesting –

• Refresh Tokens: If you enable JWT token refreshing, you can exchange your current token with a new, fresh one before the existing one expires. The new token will of course have a renewed expiry time set.
• Verify Token: If you just share the secret, all services can verify the user on their own. However, in modern micro service based architecture, you may want to provide an API end point that other services can use to verify a JWT they received from the user. This can be useful for those scenarios.
• And of course look at the settings options available and see how you can customize the token generation process.

In the future, we shall try to cover more about Django, Django REST Framework and Python in general. If you liked the content, please subscribe to the mailing list so we can notify you when we post new contents.

The post Django REST Framework: JSON Web Tokens (JWT) appeared first on Polyglot.Ninja().

Django is a Python based framework which offers developers all they need to create a web apps and websites in a clean ,rapid and a pragmatic way .

How do I start a Django project ? is the first quesion which gets asked by a beginner Django developer so lets answer it .

Tutorial requirements

To better grasp this tutorial ,you need to have some Python experience and also how to work with Linux bash commands or Windows command prompt if you are using Windows for development .

Development requirements

Before you can create or start a Django project you need to have you development environment setup .

Here is what you need to install before continuing with this tutorial :

Python 2.7.x or 3.4.x

PIP package manager

Virtualenv

Django

Code editor (Sublime,gedit etc.)

If you are using a Linux/MAC machine you should have Python already installed .

You can check that running the following command on your terminal

python -v 

If you don't have Python installed head over to Python download page

PIP is a Python package manager used to easily install Python packages and their dependencies .You can install PIP using curl utility

curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py"
python get-pip.py 

Then verify It's successfully installed

pip -V

Virtualenv is a tool which allows you to create virtual Python environments ot sandboxes .It's a common practice to create a virtual environment for each Python project to prevent different versions of packages and libraries from messing with each other .

To install Virtualenv ,run the following :

pip install virtualenv

After installing all development requirements .It's time to create a virtual development environment using Virtualenv :

mkdir django111-project
cd django111-project
virtualenv env

Then make sure to activate the environment with :

source env/bin/activate

In case you want to exit the environment ,you simply run :

deactivate

Now we are ready to install Django .

pip install django

This will install the latest Django framework version .

When writing this tutorial the latest Django version is 1.11

Create/start Django project

At this point after installing the development environment ,setting up a new virtual environment and installing the latest version of Django .You can create and start a django project by running :

django-admin.py startproject django111-project

This will create a project with a basic directory structure

├── django111-project
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   ├── wsgi.py
└── manage.py

Next navigate inside your project :

cd django111-project 

Setup a database using :

python manage.py migrate 

This will create a SQLite database which is the default option for Django project but you can also use any other advanced database system such as MySQL or PostgresSQL etc .

SQLite comes pre-installed with Python so we are going to use it for this simple project .

Then run a local development server with :

python manage.py runserver

You should be able to visit your app at :

http://127.0.0.1:8000/

Create a Django app

A Django app is a collection of apps which are used to separate logical units of your app for better project organization .

To implement any project requirements you need first to create a Django app :

python manage.py startapp app1 

Your project directory structure becomes

├── app1
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── db.sqlite3
├── django111-project
│   ├── __init__.py
│   ├── __init__.pyc
│   ├── settings.py
│   ├── settings.pyc
│   ├── urls.py
│   ├── urls.pyc
│   ├── wsgi.py
│   └── wsgi.pyc
└── manage.py

But not just that ,you need also to do some configuration .

Head over and open your project settings.py ,locate INSTALLED_APPS and your app there .

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.admin',
    'app1',
) 

Next you need to create migrations files :

python manage.py makemigrations     

Then actually run migrations to create tables related to the second app

python manage.py migrate 

Conclusion

So we have seen how to create and start a new Django project by first installing the development environment then create the actual project .

The Python language has many great frameworks for building web applications among them Django and Flask .

Both frameworks are gaining more popularity steadily in time and there are no signs they are becoming less popular or obsolete even if the web has known many important changes since the data they have been created .

Django was created in 2005 while Flask was created in 2010 .Today we are in 2017 which means Django is 12 years old and Flask is 7 years old .They are both extremely popular frameworks to build web applications with Python but they are so different in principle from each other .While Django follows a battery included approach making it a full packed ,complete and an opinionated framework ,on the other hand Flask is a micro framework ,an un-opinionated framework that let you choose what tools you can use for building a web app from the ORM to the templating engine .

In this post we'll discuss some points you might want to consider if you need to learn Django or Flask or maybe both ? and which framework you should consider using to build your next project ? and in which situations ?

They are both so popular so there are more and more websites built using both of them and more job demands for both frameworks .

Flask is a simple and flexible and lets you decide how to implement each major component such as the ORM to interact with databases ,the template engine ,forms etc .

Django is a little bit heavy when compared to Django .It has its own ORM , a template engine and even an admin back office out of the box .

Django has a predefined project directory structure while when you can structure a Flask project as you want .

When ypu should choose Flask ?

If you are just beginning web development with Python then Flask is a good option for learning purposes since you can have more control of all components of the framework .

Also if you are building small web applications then Flask can be also your to go choice .

How about Django ?

If you are a professional developer who needs to build quick prototypes or final products Django might be a good choice since it's a batteries included framework .There is a package for common web development tasks so you don't have to reinvent the wheen or waste your time building what other developers have already created .Just include the batteries and build your specefic requirements above them .

The Django ORM is easy to grasp and straightforward and lets you express your businness domain requirements clearly then you have the Django admin interface ,a complete web application that lets you do crud operations on your models such as creating ,updating ,deleting and views database records from an intuitive user interface generated for you on the fly without writing more code .

So thanks to batteries Django is your choice for either quick prototypes and final products .

Now lets see how we can create a simple Hello World web application in both frameworks :

Starting with Flask .Create a Python file

    touch webapp.py

Import Flask from flask

from flask import Flask         

Create an instance

app = Flask(__name__)

Create a view function which responds to HTTP requests and a route /

@app.route("/")
def hello():
return "Hello, World!"    

This function responds with response "Hello, World!" when thr user visit / route .

Next

if __name__ == "__main__":
app.run()  

We call the app run() method to start the web app .

Now you can run this app from terminal :

python webapp.py 

You should get

Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

If you visit this address with a web browser you should get a web page with Hello, World! response

For Django ,you should first generate a project with

django-admin startproject djwebapp 
cd djwebapp 

Next you should create an app

python manage.py startapp myapp

Then change your settings.py to include this app in Installed Apps array .

Next open myapp/views.py and create a view function

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, World!")

After that you should open your project urls.py file and add an url mapping for this view function

from django.conf.urls import url

from . import views

urlpatterns = [
    url(r'^$', views.index, name='index'),
]

You should now be able to run your web app from the terminal

python manage.py runserver

As you can see you can use Flask to rapidly create an example web app that receives http requests and responds with http responses but you need to do more work if you just to make the same example with Django .

Choosing the right framework depends on many criteria ,you should take into consideration your goals , ara you just learning server side web development or you are building a project for a client ? you should also consider your project requirements ,some projects may be better developed in Django ,some other projects can be better created in Flask .Also remember if you need grained control over each part of your framework or you need to swap and makes use of different existing tools you should use Flask where you only have the bar minimum functionality and you have to choose other components by yourself .

In this two parts tutorial ,we are going to recreate our previous Ionic 3 product inventory manager application ,which used a local SQLite database ,to use a Python Django backend .

The application we'll be creating in this tutorial uses Ionic 3 as a frontend ,Django as a backend and Django Rest Framework to create Rest API which will be consumed by Ionic .

It's a simple product inventory management application which shows you many Django concepts such as

How to create a Django project from scratch .

How to create a Django app .

How to model and create database models .

How to migrate your database .

How to generate the Admin web interface to create ,update ,delete and view database records .

How to create a super user .

How to generate a browsable and documented Rest API with Django Rest Framework .

What is Django ?

Django is a Python based web framework which encourages rapid development which is used by many web developers create web applications .It has a clean and pragmatic design which can help ypu create complete prototypes in a hours .Django packages or apps for organization and reuse .You can either create your own apps or use community created apps to sove common web development problems without reinventing the wheel .

Django has a great and helpful community ,a very good documentation and a a lot of tutorials on the web which can help you pickup easily the framework .

What is Django Rest Framework (DRF) ?

Django Rest Framework or DRF is a Django package which allows you to build or generate a full browsable and documented Rest API from your models .Thanks to DRF you can easily get an API which allows you create , update ,delete and view database records from different meduims such as mobile apps or web apps .

What is Ionic ?

Ionic is a hybrid mobile framework to create cross platform mobile apps for Android ,iOS and Universal Windows
Platform (UWP) using web technologies such as HTML ,CSS and JavaScript .Ionic 3 (The latest version of Ionic when writing this tutorial ) is based on Cordova and Angular 4 .

Install Django and Create a project

Head over your terminal or command prompt then create a new virtual environment and activate it :

virtualenv env 
source env/bin/activate 

Install the latest version of Django :

pip install django 

Start a new Django project :

django-admin startproject ProductInventoryManager 

Create an app

cd ProductInventoryManager
python manage.py startapp core 

Go to your project settings.py and add your project to the list of installed apps

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

Create your database and run a local development server :

python manage.py migrate 
python manage.py runserver 

A SQLite database will be created on your current directory .You can change the database to mySql or PostgresSQL anytime but for now lets use to a SQLite database .

A local server will be launched ,you can visit your web app at http://localhost:8200

Project requirements and database modeling

The next step is to create database models for our backend but lets first talk about our project requirements

Our product inventory system has products ,each product belongs to a family and has a location

Users need to be able to create products ,families ,locations and transactions

Users need to be able to edit products ,families ,locations and transactions

Users need to be able to delete products ,families ,locations and transactions

Users need to be able to list products ,families ,locations and transactions

Users can create products with an initial Quantity then update this Quantity using Transactions .

Now lets create our database models

Open core/models.py file and add these models :

A Product has a bunch of properties such as : Title ,Description ,Unit Price ,SKU (Stock Keeping Unit) ,Barcode (ISBN, UPC etc.) ,Quantity ,minQuantity ,Unit .

A Product belongs to a Family and has a location

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models


class Product(models.Model):

    sku = models.CharField(max_length=13,help_text="Enter Product Stock Keeping Unit")
    barcode = models.CharField(max_length=13,help_text="Enter Product Barcode (ISBN, UPC ...)")

    title = models.CharField(max_length=200, help_text="Enter Product Title")
    description = models.TextField(help_text="Enter Product Description")

    unitCost = models.FloatField(help_text="Enter Product Unit Cost")
    unit = models.CharField(max_length=10,help_text="Enter Product Unit ")

    quantity = models.FloatField(help_text="Enter Product Quantity")
    minQuantity = models.FloatField(help_text="Enter Product Min Quantity")

    family = models.ForeignKey('Family')
    location = models.ForeignKey('Location')

    def get_absolute_url(self):
        """
        Returns the url to access a particular instance of Product.
        """
        return reverse('product-detail-view', args=[str(self.id)])

    def __str__(self):

        return self.title

A Family has a : Reference,Title ,Description ,Unit ,minQuantity .

class Family(models.Model):

    reference = models.CharField(max_length=13, help_text="Enter Family Reference")
    title = models.CharField(max_length=200, help_text="Enter Family Title")
    description = models.TextField(help_text="Enter Family Description")

    unit = models.CharField(max_length=10,help_text="Enter Family Unit ")

    minQuantity = models.FloatField(help_text="Enter Family Min Quantity")

    def get_absolute_url(self):
        """
        Returns the url to access a particular instance of Family.
        """
        return reverse('family-detail-view', args=[str(self.id)])

    def __str__(self):

        return self.title

A Location has a : Reference ,Title , Description .

class Location(models.Model):

    reference = models.CharField(max_length=20, help_text="Enter Location Reference")
    title = models.CharField(max_length=200, help_text="Enter Location Title")
    description = models.TextField(help_text="Enter Location Description")

    def get_absolute_url(self):
        """
        Returns the url to access a particular instance of Location.
        """
        return reverse('family-detail-view', args=[str(self.id)])

    def __str__(self):

        return self.title

A Transaction has a : Date , Quantity , Unit Cost , Reason (New Stock - Usable Return - Unusable Return ) ,UPC (Universal Product Code ) ,Comment .

class Transaction(models.Model):

    sku = models.CharField(max_length=13,help_text="Enter Product Stock Keeping Unit")
    barcode = models.CharField(max_length=13,help_text="Enter Product Barcode (ISBN, UPC ...)")

    comment = models.TextField(help_text="Enter Product Stock Keeping Unit")

    unitCost = models.FloatField(help_text="Enter Product Unit Cost")

    quantity = models.FloatField(help_text="Enter Product Quantity")

    product = models.ForeignKey('Product')

    date = models.DateField(null=True, blank=True)

    REASONS = (
        ('ns', 'New Stock'),
        ('ur', 'Usable Return'),
        ('nr', 'Unusable Return'),
    )


    reason = models.CharField(max_length=2, choices=REASONS, blank=True, default='ns', help_text='Reason for transaction')

    def get_absolute_url(self):
        """
        Returns the url to access a particular instance of Product.
        """
        return reverse('transaction-detail-view', args=[str(self.id)])

    def __str__(self):

        return 'Transaction :  %d' % (self.id)

Registering models in admin interface

The Django admin can use your models to auto create a web interface which allows you to add ,delete ,update and view records .

To tell django about our newly created models .Open core/admin.py file the copy and paste

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.contrib import admin

from .models import Product ,Family ,Location ,Transaction  

admin.site.register(Product)
admin.site.register(Family)
admin.site.register(Location)
admin.site.register(Transaction)

Now to acess the admin web interface we need to create a super user so head over to your terminal an run

python manage.py createsuperuser 

Enter the credentials you want to use and hit Enter .

Next go to http://localhost:8200/admin then enter the credentials you just created .

You can now use the admin interface to create records for different models such as Products ,Families , Locations and Transactions .

After you successfully created your first project with Django 1.11 ,created an app and migrated your SQlite database .It's time to access the admin interface or back office generated automatically by Django which you can use to create ,delete ,edit and list your database tables data .

You can visit the admin interface from http://localhost:8200/admin

You'll be presented with a form to enter your username and password credentials .If you enter any values you'll get a message :

Please enter the correct username and password for a staff account. 
Note that both fields may be case-sensitive.

Since you have no staff user created yet but don't worry this can be fixed with one command .

Head over to your terminal ane run :

python manage.py createsuperuser

You'll be prompted for a username and a password (twice) ,enter them and hit Enter .

Next run your local server again :

python manage.py runserver 

Then visit your admin interface http://localhost:8200/admin and enter your credentials then hit Login button .

You should be successfully logged in .

In this tutorial you will learn how to setup a Django project to send emails using the Mailgun service.

Previously I’ve published in the blog a post about how to configure SendGrid to send emails. It’s a great service, but they don’t offer free plans anymore, nowadays it’s just a 30 days free trail. So, I thought about sharing the whole email setup with a better option to get started.

Mailgun is great and super easy to setup. The first 10,000 emails you send are always free. The only downside is that if you don’t provide a payment information (even though you are only going to use the first 10,000 free emails), there will be some limitations, such as requiring to configure “Authorized Recipients” for custom domains, which pretty much makes it useless, unless you know beforehand the email addresses you will be sending emails.

Anyway, let’s get started.

Initial Setup

Go to www.mailgun.com and create a free account. Sign in with your Mailgun account, click on Domains and then Add New Domain.

I will setup the Mailgun service for a domain I own, “www.bottlenose.co”. For the setup, it’s advised to use the “mg” subdomain, so you will need to provide the Domain Name like this:

mg.bottlenose.co

From now on, always change bottlenose.co with your domain name.

Click on Add Domain.

Domain Verification & DNS

To perform the next steps, you will need to access the DNS provider of your domain. Normally it’s managed by the service/website you registered your domain name. In my name, I registered the “www.bottlenose.co” domain using Namecheap.

The next steps should be more or less the name. Try to find something that says “manage”, “DNS records”, “Advanced DNS” or something similar.

DNS Records For Sending

In the Mailgun website you will see the following instructions:

Add the DNS records accordingly in your DNS provider:

DNS Records For Tracking

In a similar way, add now a CNAME for tracking opens, clicks etc. You will see those instructions:

Follow them accordingly:

Remember, in the previous screenshot you are supposed to do in your DNS provider!

Wait For Your Domain To Verify

Now it’s a matter of patience. We gotta wait for the DNS to propagate. Sometimes it can take an eternity to propagate. But my experience with brand new domains is that it usually happens very quickly. Wait like 5 minutes and give it a shot.

Click on Continue to Domain Overview:

You will now see something like this:

Click on Check DNS Records Now and see if Mailgun can verify your domain (remember, this process can take up to 48 hours!).

If the verification was successful, you will see the screen below:

Configuring Django to Send Emails

To configure you Django Project, add the following parameters to your settings.py:

EMAIL_HOST = 'smtp.mailgun.org'
EMAIL_PORT = 587
EMAIL_HOST_USER = 'postmaster@mg.bottlenose.co'
EMAIL_HOST_PASSWORD = 'mys3cr3tp4ssw0rd'
EMAIL_USE_TLS = True

Note that we have some sensitive informations here, such as the EMAIL_HOST_PASSWORD. You should not put it directly to your settings.py file or commit it to a public repository. Instead use environment variables or use the Python library Python Decouple. I have also written a tutorial on how to use Python Decouple.

Here is a very simple snippet to send an email:

from django.core.mail import send_mail

send_mail('subject', 'body of the message', 'noreply@bottlenose.co', ['vitor@freitas.com'])

And here is how the email will look like, displaying properly your domain:

If you need to keep reading about the basic email functions, check my previous article about email: How to Send Email in a Django App.

Django by default to store the files in your local file system. To make your files load quickly and secure we need to go for any third party storage systems. AWS s3 is one of the storage service for the Internet. It is designed to make web-scale computing easier for developers. django has a package called django-storages which can be used to store the files in the amazon s3. and serve them from its cloud front service.

Implementing django-storages with amazon s3 as storage service in your django application:

To implment django-storages in your django application you need to follow the following steps.

1. Install django-storages: We can install django-storages with the following command.

pip install django-storages

2. Keep storages in your installed apps.

INSTALLED_APPS = (
    ...
    'storages',
    ...
)

3. Change your DEFAULT_FILE_STORAGE setting in your settings.py file: Django by default comes with a setting called DEFAULT_FILE_STORAGE which deals with file storage. By default its value is 'django.core.files.storage.FileSystemStorage'. By keeping this value to DEFAULT_FILE_STORAGE, django, by default tries to store the files on your local machine. To store your files in amazon s3 just change that value to 'storages.backends.s3boto3.S3Boto3Storage'

DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage'

4. Configure your AWS ACCESS_KEY and SECRET_KEY with the following settings:

AWS_ACCESS_KEY_ID = "your aws access key"
AWS_SECRET_ACCESS_KEY = "your aws secret key"

5. Keep your bucket in the settings file: A bucket is a logical unit of storage in Amazon Web Services (AWS) object storage service, Simple Storage Solution S3. Buckets are used to store objects, which consist of data and metadata that describes the data. Create a bucket on AWS S3 web console and give that name in your settings file.

AWS_STORAGE_BUCKET_NAME = "your bucket name"

6. Keep file permissions with AWS_DEFAULT_ACL setting: There are some permissions for every file that is stored in your S3 bucket. There are 2 permissions in particular which will be used by default. They are private and public-read. To make a file accessable to only admin we have to make it private, If we make the file permission as public-read it can be accessable to public with read permissions.

AWS_DEFAULT_ACL = "public-read" # to make sure all your files gives read only access to the files

7. Keep your file specific meta information with AWS_HEADERS: This setting will be useful in keeping the file's meta information like Expires and Cache-Control which will play major role in the google page speed score. In fixing the Leverage Browser Caching issue we have to keep Cache-Control setting value and keep Expires value in fixing the keep expiration header issue in your google page speed validator.

AWS_HEADERS = {
    'Expires': 'Thu, 15 Apr 2010 20:00:00 GMT',
    'Cache-Control': 'max-age=86400',
}

By keeping all the above settings, we are ready to use the AWS S3 as a storage service for all the files in our project. But to make our files serve from cloud front we have keep other settings that relates to cloudfront in our application.

What is cloud front?

Amazon CloudFront is a web service that speeds up distribution of your static and dynamic web content, such as .html, .css, .php, and image files, to your users. CloudFront delivers your content through a worldwide network of data centers called edge locations. When a user requests content that you're serving with CloudFront, the user is routed to the edge location that provides the lowest latency (time delay), so that content is delivered with the best possible performance. 

To make sure our files served from cloudfront we have to keep the following settings in our application.

CLOUDFRONT_DOMAIN = "your cloudfornt domain"
CLOUDFRONT_ID = "your cloud front id"
AWS_S3_CUSTOM_DOMAIN = "same as your cloud front domain" # to make sure the url that the files are served from this domain

Thats all you have to do, now all the files that the user uploads or the static files will be stored in the S3 bucket that you gave and served from cloudfront. To make your static files load from cloudfront, first you need to do python manage.py collectstatic, using which all your static CSS and JS files will be stored in your S3 bucket under the folder of STATICFILES_DIR setting you gave.

This is an interview I took from Django core developer Andrew Godwin about deployment. Recorded in DjangoCon EU 2017, Florence, Italy.

https://djangodeployment.com/wp-content/uploads/2017/05/godwin.mp3

 

ANT: Hello everyone! This is Antonis from djangodeployment.com. It’s 5 April 2017 and I am at the European Django Conference in Florence. I am sitting with Andrew Godwin, who is a Django core developer mostly known as the creator of migrations and now Django Channels, and we are going to have a little chat about deployment. Hello Andrew!

AND: Hello! It’s lovely to talk to you!

ANT: Thanks! Some years ago you tried to create a deployment service which was called epio. So, could you tell me a little bit more about that?

AND: Of course! As a bit of background history, we’re talking quite a few years now when Heroku was just for Ruby at the time, and so I was sitting in DjangoCon US and me and a friend had the idea to, why not do Heroku for Python?, which of course was an idea common to several startups at that time. We took on the challenge of making a platform-as-a-service, which is what Heroku of course is. I think it was two or three years from start to end of that project. It was quite difficult, and eventually we sort of shut down gradually, the company itself moved to a project then called Orchard, which then later got sold on to Docker, Inc, so it still had a history through that time, but I left it around four years ago.

ANT: One question that I’ve been having about deployment, because I started a blog and a book about deployment and I see that people are really interested: So I asked my readers, why do you care when you can just press a button in Heroku and have your application deployed? I got a number of answers but I’d like to have your viewpoint.

AND: So that’s a very interesting and common question of course, and I have a number of different viewpoints. The first one for me is cost, ultimately. Heroku is very expensive for what they give you in terms of resources. Obviously the value out there is in terms of management and time saving and wages, but in general I would say that, as someone who’s experienced in deployment, I can do that. If that is in my range, I don’t need to spend too much for it. And the other part is customization. Heroku, I would say, is very good for a small or medium sized web site where you fit into the common pattern, but as you grow you inevitably become more specialized. You require different kinds of routing or network or storage and that’s the point where I think that something like Heroku restrains to make everything work, you can’t have one pattern that works for every big site. Now, would I recommend it? For a small site, absolutely. Would I run it? No. But that’s two very different things.

ANT: I think that services like Heroku, or, maybe, the Divio cloud, they treat deployment as a black box. That is essentially their purpose, to make deployment simpler for you, so you are not supposed to know anything about it. But do things eventually go wrong? And when things go wrong, is it useful to have knowledge of the mechanics of deployment in order to fix things? Or is it maturing now? Is it a matter of maturity?

AND: So it’s not just maturity, it’s also about how well you are equipped to deal with these problems. Having full knowledge of the system is not useful if you don’t have the resources to fix that system. You just know about your failure rather than not knowing about your failure. So I think it is in some cases better to know of a failure and be able to fix it, but doing that requires a lot of expertise that is hard to find, like good operations people are very very thin on the ground in almost every part of the world. So it really depends, is it worth for you to know how to fix the black box or can you take the failure? One good example that isn’t about deployment is a database. If MySQL or PostgreSQL fails, it’s technically open source, you can, in theory, go and fix it, but in all likelihood you don’t have the knowledge or the ability to fix the problem in PostgreSQL, and so, it’s not about if it’s technically close, it’s also if it’s by the nature of its complexity close to you. If I made you a system that is fully open, and gave you that system with the ssh keys and everything, but you didn’t know how it worked, it would still be effectively a black box, but now it’s a black box with no support contract. In a lot of cases it’s best to have a black box with a support contract than something you half-know yourself.

ANT: People compare Django deployment to PHP deployment, because PHP has a fame for easy deployment—you just throw your files in a directory and it just works. Is there any fundamental reason why Django has to be harder? And a related question is, is PHP deployment really simpler, or is it deceptive to think that you can just throw your files in a directory and that’s it?

AND: There’s two parts to that question. The first one that I will address is, is it really simpler? The answer is, for a small project yes. PHP has the unenviable ability to just take a directory, put a file in there, and you’re off. And for that reason I came into web development from PHP. I had my problems with it as a language but I still respect the ease of use of it. The problem is that simplicity quickly becomes irrelevant as you get bigger and bigger, and one of the downsides of PHP can often be, yes it is a directory, and so you have to have an htaccess file in the old days, there’s a few more security issues. In Python and Django it’s just having standards. Before the advent of WSGI—when I started doing Django WSGI was there but very new—it was much harder, you had to sort of find a custom web server, wrangle with it, and it wasn’t particularly right. So we have come a long way in having a standard where you can pick anyone of uWSGI, mod_wsgi, Gunicorn, a number of other servers, plug any Python application into them, and there you go. It is more difficult, but it’s only very marginally more difficult. And ultimately I think, what I see the difference is with PHP you can drag-and-drop files in an interface, with Django you need to have some command line access. I think for some people just the presence of a command line makes it seem more difficult—it may not be more difficult but it makes it seem more difficult. That’s ultimately the sticking point some people have.

ANT: One example I have been thinking about that, a very simple one, is that when you deploy you also need to setup the email settings so that it can email you in case of an error, and for people who have no experience in deployment this is also something that they have to learn. You have to do this also in PHP I guess.

AND: Of course, you do, the difference there being that PHP is not setup to email you errors by default. If you configure it you can make it show a 500 page; if you do it incorrectly, as if you leave DEBUG on Django, it will show you a full traceback and all these wonderful variables and things exposed in there. So it’s more the case that out of the box Django is looking for an email address to send errors to. In a way that might be outdated by itself, for example I use something like Sentry more often than emails, my mailbox is already full enough. It’s just the defaults, the way it arrives, like, you install Django, you open that settings file, and there’s like 40 different things that you’re like “Oh! Do I need this? Do I fill it in?” and one of those is the email address.

ANT: OK. This is everything, so thank you Andrew and thanks everyone for listening.

Did you like this post?

Interview
© 2017 Antonis Christofides and Andrew Godwin.
The interview is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License.

Photo by Bartek Pawlik
© 2017 DjangoCon Europe 2017
Original photo

The post Interview with Andrew Godwin about deployment appeared first on Django deployment.

When considering a website upgrade, many business stakeholders probably think about the frontend, i.e., how the website looks or the features users interact with. Perhaps less often considered is the importance of upgrading the backend; that is, the databases, applications, and servers powering all the behind-the-scenes activity. Infrastructure support and upgrades are necessary but often performed as a separate project from any improvements to design or user experience, rather than as part of a holistic update project.

With that in mind, it helps to have an understanding of why upgrading the backend should be considered a necessary part of any website upgrade project. We offer 3 reasons, focusing on our specialty of Django-based websites. Upgrading:

• increases security,
• reduces development and maintenance costs, and
• ensures support for future growth.

Read on for details about each of these factors, or get in touch to speak with us about them.

Increase the security of your site

The Django framework is continually being improved and certain releases are designated as “Long Term Support” (LTS) versions. LTS versions receive security updates and bug fixes for a three-year period, as opposed to the usual 18 months. When your website uses an unsupported version of Django, newly uncovered bugs are not being fixed, patched, or supported by the Django and Open Source communities. No new security fixes are planned for retired versions, a situation that carries a number of risks.

These risks come in the form of vulnerabilities - weaknesses that leave your site open to attack. Attacks could potentially cause servers to go down, data to be leaked or stolen, or features to stop working. If a vulnerability is taken advantage of, it could lead to a loss of reputation and potentially a loss of revenue or legal ramifications. With high consumer expectations and increasing requirements from international data protection laws, this could prove disastrous for organizations or web applications without stringent upgrade plans in place.

If your site is using an older version of Django, a security patch may not be released for your version of Django. This means that a fix for the vulnerability would have to be authored and implemented by your development team, which, over time, is less cost effective than upgrading to the LTS version.

Upgrading to an LTS release offers significant benefits, including security updates as needed. Fixes for security issues and vulnerabilities are implemented quickly. There is no need to implement fixes yourself (or hire out expensive custom work). Taking proactive steps to upgrade reduces risk and can save you the trouble of expensive, reactive steps in the event of a cyberattack.

Reduce development and maintenance costs

In addition to improving security and ensuring support for future growth, upgrading also offers productivity benefits for development teams. Many extra lines of code may be required in order to continue to backport fixes for your website or app as issues occur or features are added. Adding all this code and continuing to use old versions of Django will eventually lead to technical debt, where the short-term fixes and outdated code end up creating extra work to patch and maintain a project in the long run.

Custom fixes and patches also introduce a large learning curve for new developers or contractors. The issue here is two-fold: Onboarding new developers is more time consuming than it needs to be, and if key personnel leave, you may lose knowledge which is integral to maintaining or updating the project.

Upgrading your version of Django reduces technical debt by eliminating old, no-longer-needed code. It also allows your development team to reduce the time and money spent on addressing security issues and bug fixes, freeing up time for them to work on website improvements or revenue-generating work.

Ensure support for future growth

Extensibility is the practice of keeping future growth in mind when working on a development project. We often hear from potential clients who built a website or web app in the early days of their business, when releasing features quickly took precedence over planning for future growth. Whether that growth is in the form of more data, more users, or more functionality, planning for it impacts current design and development decisions. When growth isn’t considered, scaling up the project and adding new features requires a disproportionate amount of work. If the original development was not intended to support the changes being made, custom workarounds must be introduced.

Where does this leave your web project? Technologically out of date, unnecessarily clunky, and less able to deliver a quality experience to site visitors.

Upgrading Django from an out-of-date version to a more recent LTS version not only provides access to software that is constantly receiving bug and security fixes; it also simplifies the upgrade process when a new version of Django is released with a feature needed by your project. If your project is two, three, even four releases behind, upgrading all at once could be cost-prohibitive. By regularly upgrading, you gain near-immediate access to new features in Django if and when needed. In other words, you can depend on a highly-engaged developer community actively working to add features rather than reinventing the wheel by developing them yourself.

Next steps

The wider open source development community is producing great tools and enhancements every day and the community continues to grow in size and support. Your project may find itself left behind if Django is left unsupported - or growing along with the community if you upgrade.

So where to get started? For clients considering an upgrade, we generally advise moving up to the most recent LTS release. While the latest version of Django offers the newest features, the LTS version represents a version of Django that will be more cost efficient to maintain given the community’s three-year commitment to releasing updates for it.

As Django specialists, Caktus developers have experience upgrading and maintaining Django-based websites. We have successfully completed upgrades for numerous clients and offer an upgrade protection plan that ensures your site will be maintained year to year as well as updated to the most recent LTS version of Django. Sound good? Get in touch to start the process of upgrading and securing your website, or take a look at some of our other services if you’ve got a larger project in mind.

In Developing an application, we'll write our required API's. To Document these API's we use Django Rest Swagger.

Django Rest Swagger is used to Document your API for eg., Listing all Your project Rest API's in the browser with brief description abou the API.

It is Open Source so you can contribute to the project.

If your API's available to the users with description, so UI developers can understand and test your API's and use it accordingly.

First we need to install the swagger.

pip install django-rest-swagger

Add "rest_framework_swagger" to Django settings INSTALLED_APPS

INSTALLED_APPS = (

    ...

    'rest_framework_swagger',

)

Include the rest_framework_swagger URLs to a path of your choice

patterns = ('',

    ...

    url(r'^docs/$', schema_view, name="schema_view"),

)

In your API Views

from rest_framework.decorators import api_view, permission_classes, renderer_classes

from rest_framework.permissions import AllowAny

from rest_framework_swagger.renderers import OpenAPIRenderer, SwaggerUIRenderer

@api_view()

@permission_classes((AllowAny, ))

@renderer_classes([OpenAPIRenderer, SwaggerUIRenderer])

def schema_view(request):

    generator = schemas.SchemaGenerator(title='Rest Swagger')

    return Response(generator.get_schema(request=request))

If you are not authorized, This document List all the API which doesnt reguire any permission to get authorize.

If you want to authorize user you need to add these swagger settings in your settings.py file. By this you will be provide with Authorize Button in the header when user hits the swagger document URL, When you click on it you will be prompt with a pop-up to enter details of Api key authorization. By providing your API Key the user gets Authorize.

SWAGGER_SETTINGS = {

    'USE_SESSION_AUTH': False,

    'api_version': '0.1',

    'enabled_methods': [

        'get',

        'post',

    ],

    'SECURITY_DEFINITIONS': {

        "api_key": {

            "type": "apiKey",

            "name": "Authorization",

            "in": "header"

          },

    },

}