original source : https://www.micahcarrick.com/django-email-authentication.html

아래 예제 코드에 오류가 있어서 2군데 수정하고 기본적으로 intent 의 수정이 필요하다.

django는 username과 password를 이용해 authentication 작업을 하는데 이를 email 과 password로 바꾸는 작업을 설명하고 있다.

Django Authentication using an Email Address

The Django authentication system provided in django.contrib.auth requires the end user to authenticate themselves using a username and password. However, it is often desireable to allow users to log in using an email address rather than a username. There are a few different ways to accomplish this and a lot of discussion on the topic.

In this approach, I use a custom authentication backend to authenticate a user based on his or her email address, I hide the username from the end user, I generate a random username for the user when creating an account, and I manually add a unique index to the email column in the database (this is a bit of a “hack”).

Why email authentication?

The web has evolved and these days many of us have dozens (hundreds?) of accounts around the web. Remembering all those usernames and passwords can be a real chore. That “forgot password” feature suddenly becomes a standard step in the log in process for many users. When ease-of-use is paramount in your authentication system, such as customer accounts on e-commerce websites, you want to require as little effort from the end user as possible. Most people already remember their email address. One less piece of information to remember.

Why not email authentication?

Yes, this post is about using email authentication, but it has it’s down side as well. We know users forget their passwords quite often. Users can also lose their email address when they change jobs, schools, or their domain name expires. If a user has lost access to the email they used in your system and they do not remember their password then there is nothing they can do short of starting a new account on your site (unless you implement something to specifically address this scenario). For some applications this is an acceptable trade-off for the usability gained by using email authentication.

Problems Presented with Email Authentication in Django

The email address is not unique.

The Django authentication system uses the a username to uniquely identify a user. While this is often used as a “display name” as well, it’s primary function is as a unique identifier for a user. In theory, Django’s auth system could allow two users to share the same email address and thus, the email address does not uniquely identify a user.

There is no database index on the email address.

If the authentication system is going to be querying users on their email address, the database column storing that email address would need to have an index. The datatbase table created by the Django authentication, auth_user, does not have any index on the email address, let alone a unique index.

The username is limited to 30 characters.

Some people implement email authentication in Django by putting the email address into the username field. The problem with this is that the username field is limited to 30 characters and many (about 15% on one of my websites) are longer than 30 characters.

Other code relies on django.contrib.auth.

There are a lot of other Django apps, both built-in and 3rd party, that make use of Django’s authentication system. Thus, it is ideal to work with Django’s authentication system opposed to “rolling your own” system.

A Custom Backend Solution for Email Authentication in Django

The approach I have opted for begins with a custom authentication backend. The code below defines the backend that django.contrib.auth will use instead of the default backend. The username passed to the authenticate() method is assumed to be an email address and the user is queried based on the email instead of the username.

(아래 코드에서 from django.contrib.auth.models import User, check_password 이렇게 원래는 되어있었으나 check_password를 삭제했다.)


from django.contrib.auth.models import User
class EmailAuthBackend(object):
	Email Authentication Backend

	Allows a user to sign in using an email/password pair rather than
	a username/password pair.
	def authenticate(self, username=None, password=None):
		""" Authenticate a user based on email address as the user name. """
			user = User.objects.get(email=username)
			if user.check_password(password):
				return user
			except User.DoesNotExist:
				return None
	def get_user(self, user_id):
		""" Get a User object from the user_id. """
			return User.objects.get(pk=user_id)
	except User.DoesNotExist:
		return None

You can then use the AUTHENTICATION_BACKENDS setting in your settings.py file to tell the django authentication system to use your custom backend.


AUTHENTICATION_BACKENDS = ('backends.EmailAuthBackend',)

Renaming the “Username” Field to “Email address”

Since the custom authorization backend assumes the username passed to it is an email address, the standard authentication form works just fine. The user just enters an email address instead of a username. However, the form still has the username field and that field is still labeled “Username”.

Since I prefer more granular control over the layout of the forms in the authentication process, I opted to let the login form template handle changing the label of the authentication form. An alternative approach would have been to subclass django.contrib.auth.forms.AuthenticationForm and rename the field’s label there.

templates/login_form.html (example snippet)

<form action="." method="post">
	{% csrf_token %}
	<input type="hidden" name="next" value="{{ next }}" />
	{{ form.non_field_errors }}
	{% for field in form %}
 <div class="field-wrapper">
	<div class="label-wrapper">
		{% if field.name == "username" %}
			Email address
		{% else %}
			{{ field.label_tag }}
		{% endif %}
		{% if field.field.required %}<span class="required">*</span>{% endif %}
	<div class="value-wrapper">
		{{ field }}
		{{ field.errors }}
 {% endfor %}
 <div class="submit-wrapper">
 <input type="submit" value="Sign In" />

A Custom Sign Up Form (User Creation Form)

Since an email address is now required to authenticate a user, it needs to be a required field on the user creation form as well. This can be done by subclassing the UserCreationForm.

(아래코드에서 except 구문아래 pass가 없었는데 내가 넣었다.)


from django.contrib.auth.forms import UserCreationForm
from django.contrib.auth.models import User
from django import forms

class SignUpForm(UserCreationForm):
	""" Require email address when a user signs up """
	email = forms.EmailField(label='Email address', max_length=75)
	class Meta:
		model = User
		fields = ('username', 'email',)
	def clean_email(self):
		email = self.cleaned_data["email"]
		user = User.objects.get(email=email)
		raise forms.ValidationError("This email address already exists. Did you forget your password?")
	except User.DoesNotExist:
		return email
	def save(self, commit=True):
		user = super(UserCreationForm, self).save(commit=False)
		user.email = self.cleaned_data["email"]
		user.is_active = True # change to false if using email activation
		if commit:
		return user

Now the email address is added to the form, however, the username is still a required field as well. That may suit your needs, however, my goal is to keep the process as simple as possible for the end user. I do not want to remove the username, I just want to hide it from the end user. So I simply hide the username field in the template for the form and then auto-generate a random username in the view.

templates/sign_up.html (example snippet)

<form action="." method="post">
	{% csrf_token %}
	{{ form.non_field_errors }}
	{% for field in form %}
		{% if field.name != "username" %}
			<div class="field-wrapper">
				<div class="label-wrapper">
					{{ field.label_tag }}
					{% if field.field.required %}<span class="required">*</span>{% endif %}
				<div class="value-wrapper">
					{{ field }}
					{{ field.errors }}
		{% endif %}
	{% endfor %}
	<div class="submit-wrapper">
		<input type="submit" value="Sign Up"/>

Generating a Random Username in the View

Since the username field was omitted from the sign up form template, the view that processes the form needs to create one. The example view below generates a random 30-character username.

from django.template import RequestContext
from django.shortcuts import render_to_response
from django.http import HttpResponseRedirect
from forms import SignUpForm
from random import choice
from string import letters

def sign_up(request):
	""" User sign up form """
	if request.method == 'POST':
		data = request.POST.copy() # so we can manipulate data
	# random username
	data['username'] = ''.join([choice(letters) for i in xrange(30)])
	form = SignUpForm(data)
	if form.is_valid():
		user = form.save()
		return HttpResponseRedirect('/sign_up_success.html')
		form = SignUpForm()

	return render_to_response('sign_up.html', {'form':form}, context_instance=RequestContext(request))

Adding a Unique Index to the Email Column

The only part of this email authentication solution that I really do not like is that I have am manually adding a unique index to the email address column in the database (I use MySQL). Please post a comment with your suggesions for a better solution.

I know of some people who use the email address in a custom profile, however I don’t like the redundancy nor having the primary unique identifier for a user in a separate table. The ideal solution for me would be to have some code that can unobtrusively add a unique index to the auth_user table through Django’s database abstraction.



required form field를 위한 model field 설정



p103 Model EmailField()

p104 null=True , blank=True

p105 model verbose_name option

p106-7 admin.py admin.ModelAdmin을 통해 admin 에서 볼수 있는 model들의 설정을 바꿀수 있다.

p107 admin.py admin.ModelAdmin 를 통해서 admin 화면 customizing이 가능하다.

p120 HttpRequest.META 안에 각종 header정보가 있다.

p124- 126 basic form GET 사용법

p133 basic form POST 작동원리 and 에러 

forms.ModelForm customizing하기

p136 forms.Form의 다른 widget으로 바꾸기

p138 forms.Form의 기본 validation 규칙 , 기본값 설정하기 

p139 custom validation 설정하기, label바꾸기

p140 field별로 html tag , message 출력하기

p147 공통된 url prefix를 설정하기

p162 wrapper를 이용해 여러 view들에 사전 작업을 처리할수 있다. (ex login wrapper) decorator와 같은 원리 이다.

p163 urls include

p174 template autoescape off 하는 방법

p176 {{data | default:”3 &lt; 2”}} template에서 기본값설정하는데 special character escaped

p256 cookies에 접근하는 법

p258 session 이용

p261 session check

p264 request.user

p265 request.user.is_authenticated()

p277 auth.authenticate() 와 auth.login()와 auth.logout()

p269 login_required decorator

p270 permission_required decorator


p271 creating user, set password , check password

  • User.objects.create_user(), User.set_password(), User.check_password()

p273 template에서 authentication data 사용하기

django docs Form 기본

django docs ModelForm

Using the Django authentication system


creating form from model


working with form


modelform customizing


customizing UserCreationForm


adjusting height with bootstrap



(input 의 높이를 지정하는 방법으로 percentage사용불가)

PasswordInput() 사용예시


message framework (ontime message to next view)


using authentication system in django


AuthenticationForm 수정 custom customizing하기


AuthenticationForm수정 custom customizing하기


original source : https://docs.djangoproject.com/en/3.0/topics/signals/


Django includes a “signal dispatcher” which helps allow decoupled applications get notified when actions occur elsewhere in the framework. In a nutshell, signals allow certain senders to notify a set of receivers that some action has taken place. They’re especially useful when many pieces of code may be interested in the same events.

Django provides a set of built-in signals that let user code get notified by Django itself of certain actions. These include some useful notifications:

Sent before or after a model’s save() method is called.

Sent before or after a model’s delete() method or queryset’s delete() method is called.

Sent when a ManyToManyField on a model is changed.

Sent when Django starts or finishes an HTTP request.

See the built-in signal documentation for a complete list, and a complete explanation of each signal.

You can also define and send your own custom signals; see below.

Listening to signals

To receive a signal, register a receiver function using the Signal.connect() method. The receiver function is called when the signal is sent. All of the signal’s receiver functions are called one at a time, in the order they were registered.

(Signal에 특정 sender에만 반응하는 receiver를 연결, dispatch_uid를 이용 중복을 막는다.)

Signal.connect(receiver, sender=None, weak=True, dispatch_uid=None)



  • receiver – The callback function which will be connected to this signal. See Receiver functions for more information.
  • sender – Specifies a particular sender to receive signals from. See Connecting to signals sent by specific senders for more information.
  • weak – Django stores signal handlers as weak references by default. Thus, if your receiver is a local function, it may be garbage collected. To prevent this, pass weak=False when you call the signal’s connect() method.
  • dispatch_uid – A unique identifier for a signal receiver in cases where duplicate signals may be sent. See Preventing duplicate signals for more information.

Let’s see how this works by registering a signal that gets called after each HTTP request is finished. We’ll be connecting to the request_finished signal.

Receiver functions

First, we need to define a receiver function. A receiver can be any Python function or method:

def my_callback(sender, **kwargs):
    print("Request finished!")

Notice that the function takes a sender argument, along with wildcard keyword arguments (**kwargs); all signal handlers must take these arguments.

We’ll look at senders a bit later, but right now look at the **kwargs argument. All signals send keyword arguments, and may change those keyword arguments at any time. In the case of request_finished, it’s documented as sending no arguments, which means we might be tempted to write our signal handling as my_callback(sender).

This would be wrong – in fact, Django will throw an error if you do so. That’s because at any point arguments could get added to the signal and your receiver must be able to handle those new arguments.

Connecting receiver functions

두가지 방법이 있으며 하나는 Signal.connect()를 이용하는 것과 decorator를 이용하는 것이다.

There are two ways you can connect a receiver to a signal. You can take the manual connect route:

from django.core.signals import request_finished


Alternatively, you can use a receiver() decorator:



Parameters:signal – A signal or a list of signals to connect a function to.

Here’s how you connect with the decorator:

from django.core.signals import request_finished
from django.dispatch import receiver

def my_callback(sender, **kwargs):
    print("Request finished!")

Now, our my_callback function will be called each time a request finishes.

Where should this code live?

Strictly speaking, signal handling and registration code can live anywhere you like, although it’s recommended to avoid the application’s root module and its models module to minimize side-effects of importing code.

(receiver는 보통 signals이라는 module에 넣어 보관한다.)

In practice, signal handlers are usually defined in a signals submodule of the application they relate to. Signal receivers are connected in the ready() method of your application configuration class. If you’re using the receiver() decorator, import the signals submodule inside ready().



The ready() method may be executed more than once during testing, so you may want to guard your signals from duplication, especially if you’re planning to send them within tests.

Connecting to signals sent by specific senders

(sender를 지정해서 특정 작업에만 반응하게 한다.)

Some signals get sent many times, but you’ll only be interested in receiving a certain subset of those signals. For example, consider the django.db.models.signals.pre_save signal sent before a model gets saved. Most of the time, you don’t need to know when any model gets saved – just when one specific model is saved.

In these cases, you can register to receive signals sent only by particular senders. In the case of django.db.models.signals.pre_save, the sender will be the model class being saved, so you can indicate that you only want signals sent by some model:

from django.db.models.signals import pre_save
from django.dispatch import receiver
from myapp.models import MyModel

@receiver(pre_save, sender=MyModel)
def my_handler(sender, **kwargs):

The my_handler function will only be called when an instance of MyModel is saved.

Different signals use different objects as their senders; you’ll need to consult the built-in signal documentation for details of each particular signal.

Preventing duplicate signals

In some circumstances, the code connecting receivers to signals may run multiple times. This can cause your receiver function to be registered more than once, and thus called multiple times for a single signal event.

If this behavior is problematic (such as when using signals to send an email whenever a model is saved), pass a unique identifier as the dispatch_uid argument to identify your receiver function. This identifier will usually be a string, although any hashable object will suffice. The end result is that your receiver function will only be bound to the signal once for each unique dispatch_uid value:

from django.core.signals import request_finished

request_finished.connect(my_callback, dispatch_uid="my_unique_identifier")

Defining and sending signals

(커스텀 Signal 이용하기)

Your applications can take advantage of the signal infrastructure and provide its own signals.

When to use custom signals

Signals are implicit function calls which make debugging harder. If the sender and receiver of your custom signal are both within your project, you’re better off using an explicit function call.

Defining signals

class Signal(providing_args=list)


All signals are django.dispatch.Signal instances. The providing_args is a list of the names of arguments the signal will provide to listeners. This is purely documentational, however, as there is nothing that checks that the signal actually provides these arguments to its listeners.

For example:

import django.dispatch

pizza_done = django.dispatch.Signal(providing_args=["toppings", "size"])

This declares a pizza_done signal that will provide receivers with toppings and size arguments.

Remember that you’re allowed to change this list of arguments at any time, so getting the API right on the first try isn’t necessary.

Sending signals

There are two ways to send signals in Django.

Signal.send(sender, **kwargs)


Signal.send_robust(sender, **kwargs)


To send a signal, call either Signal.send() (all built-in signals use this) or Signal.send_robust(). You must provide the sender argument (which is a class most of the time) and may provide as many other keyword arguments as you like.

For example, here’s how sending our pizza_done signal might look:

class PizzaStore:

    def send_pizza(self, toppings, size):
        pizza_done.send(sender=self.__class__, toppings=toppings, size=size)

Both send() and send_robust() return a list of tuple pairs [(receiver, response), ... ], representing the list of called receiver functions and their response values.

send() differs from send_robust() in how exceptions raised by receiver functions are handled. send() does not catch any exceptions raised by receivers; it simply allows errors to propagate. Thus not all receivers may be notified of a signal in the face of an error.

send_robust() catches all errors derived from Python’s Exception class, and ensures all receivers are notified of the signal. If an error occurs, the error instance is returned in the tuple pair for the receiver that raised the error.

The tracebacks are present on the __traceback__ attribute of the errors returned when calling send_robust().

Disconnecting signals

Signal.disconnect(receiver=None, sender=None, dispatch_uid=None)


To disconnect a receiver from a signal, call Signal.disconnect(). The arguments are as described in Signal.connect(). The method returns True if a receiver was disconnected and False if not.

The receiver argument indicates the registered receiver to disconnect. It may be None if dispatch_uid is used to identify the receiver.

original source: https://github.com/divanov11/crash-course-CRM/blob/Part-7-Database-Queries/crm1_v7_database_queries/accounts/queryDemos.py

#***(1)Returns all customers from customer table
customers = Customer.objects.all()

#(2)Returns first customer in table
firstCustomer = Customer.objects.first()

#(3)Returns last customer in table
lastCustomer = Customer.objects.last()

#(4)Returns single customer by name
customerByName = Customer.objects.get(name='Peter Piper')

#***(5)Returns single customer by name
customerById = Customer.objects.get(id=4)

#***(6)Returns all orders related to customer (firstCustomer variable set above)

#(7)***Returns orders customer name: (Query parent model values)
order = Order.objects.first() 
parentName = order.customer.name

#(8)***Returns products from products table with value of "Out Door" in category attribute
products = Product.objects.filter(category="Out Door")

#(9)***Order/Sort Objects by id
leastToGreatest = Product.objects.all().order_by('id') 
greatestToLeast = Product.objects.all().order_by('-id') 

#(10) Returns all products with tag of "Sports": (Query Many to Many Fields)
productsFiltered = Product.objects.filter(tags__name="Sports")

Q: If the customer has more than 1 ball, how would you reflect it in the database?
A: Because there are many different products and this value changes constantly you would most 
likly not want to store the value in the database but rather just make this a function we can run
each time we load the customers profile

#Returns the total count for number of time a "Ball" was ordered by the first customer
ballOrders = firstCustomer.order_set.filter(product__name="Ball").count()

#Returns total count for each product orderd
allOrders = {}

for order in firstCustomer.order_set.all():
	if order.product.name in allOrders:
		allOrders[order.product.name] += 1
		allOrders[order.product.name] = 1

#Returns: allOrders: {'Ball': 2, 'BBQ Grill': 1}

class ParentModel(models.Model):
	name = models.CharField(max_length=200, null=True)

class ChildModel(models.Model):
	parent = models.ForeignKey(Customer)
	name = models.CharField(max_length=200, null=True)

parent = ParentModel.objects.first()
#Returns all child models related to parent

original source: https://docs.djangoproject.com/en/3.0/ref/applications/#django.apps.AppConfig


(여기 doc에서는 app의 개념이다. 전체구성은 project라한다.)

Django contains a registry of installed applications that stores configuration and provides introspection. It also maintains a list of available models.

This registry is called apps and it’s available in django.apps:

>>> from django.apps import apps
>>> apps.get_app_config(‘admin’).verbose_name ‘Administration’

django는 각각의 설치된 app의 설정들을 apps이라는 registry(목록) 안에 보관하며 이를 통해 introspection이 가능하게 한다. 또한 사용가능한 model들을 관리한다.

Projects and applications

The term project describes a Django web application. The project Python package is defined primarily by a settings module, but it usually contains other things. For example, when you run django-admin startproject mysite you’ll get a mysite project directory that contains a mysite Python package with settings.py, urls.py, asgi.py and wsgi.py. The project package is often extended to include things like fixtures, CSS, and templates which aren’t tied to a particular application.

django-admin startproject 명령을 통해 만들어지는 것이 project이다. 이안에 settings.py, urls.py, asgi.py and wsgi.py. 이 있으며 fixtures, CSS, and templates 들도 포함된다.

A project’s root directory (the one that contains manage.py) is usually the container for all of a project’s applications which aren’t installed separately.

The term application describes a Python package that provides some set of features. Applications may be reused in various projects.

application은 python manage.py startapp 명령을 통해 만들어진다. 

Applications include some combination of models, views, templates, template tags, static files, URLs, middleware, etc. They’re generally wired into projects with the INSTALLED_APPS setting and optionally with other mechanisms such as URLconfs, the MIDDLEWARE setting, or template inheritance.

app은 보통 INSTALLED_APPS에 기입함으로써 프로젝트에 연결된다.

It is important to understand that a Django application is a set of code that interacts with various parts of the framework. There’s no such thing as an Application object. However, there’s a few places where Django needs to interact with installed applications, mainly for configuration and also for introspection. That’s why the application registry maintains metadata in an AppConfig instance for each installed application.

app은 obj로 존재하지 않는다. django가 app과 상호반응해야 하는데(주로 configuration, introspection의 목적으로) 그런 목적으로 apps registry의 AppConfig안에 metadata를 유지한다.  

There’s no restriction that a project package can’t also be considered an application and have models, etc. (which would require adding it to INSTALLED_APPS).

Configuring applications

To configure an application, subclass AppConfig and put the dotted path to that subclass in INSTALLED_APPS.

When INSTALLED_APPS contains the dotted path to an application module, Django checks for a default_app_config variable in that module.

INSTALLED_APPS 안에 . path 형태로 app 의 module경로가 지정되어있는 경우 해당 module의 __init__.py 안의 default_app_config 를 확인하게 된다.

If it’s defined, it’s the dotted path to the AppConfig subclass for that application.

default_app_config 안에는 .  path 형태로 AppConfig 를 implement한 subclass 위치가 지정되어야한다.

If there is no default_app_config, Django uses the base AppConfig class.

default_app_config allows applications that predate Django 1.7 such as django.contrib.admin to opt-in to AppConfig features without requiring users to update their INSTALLED_APPS.

이부분은 정확하게 이해하지는 않았다. 추측해보면 ‘default_app_config 를 설정해서 app을 만든경우 app을 사용하는 다른 사용자(개발자)가 INSTALLED_APPS에 기입하지 않고도 사용가능하다’ 인것 같다.

New applications should avoid default_app_config. Instead they should require the dotted path to the appropriate AppConfig subclass to be configured explicitly in INSTALLED_APPS.

app을 만들 경우 default_app_config 를 설정할 필요는 없으며 보통 INSTALLED_APPS에 AppConfig subclass 까지의 경로를 직접 . path형태로 기입하면 된다.

For application authors

If you’re creating a pluggable app called “Rock ’n’ roll”, here’s how you would provide a proper name for the admin:

# rock_n_roll/apps.py

from django.apps import AppConfig

class RockNRollConfig(AppConfig):
    name = 'rock_n_roll'
    verbose_name = "Rock ’n’ roll"

You can make your application load this AppConfig subclass by default as follows:

# rock_n_roll/__init__.py

default_app_config = 'rock_n_roll.apps.RockNRollConfig'

That will cause RockNRollConfig to be used when INSTALLED_APPS contains 'rock_n_roll'. This allows you to make use of AppConfig features without requiring your users to update their INSTALLED_APPS setting. Besides this use case, it’s best to avoid using default_app_config and instead specify the app config class in INSTALLED_APPS as described next.

Of course, you can also tell your users to put 'rock_n_roll.apps.RockNRollConfig' in their INSTALLED_APPS setting. You can even provide several different AppConfig subclasses with different behaviors and allow your users to choose one via their INSTALLED_APPS setting.

app 개발자는 두가지 선택지를 가진다. 하나는 default_app_config 를 설정함으로써 app의 사용자(다른개발자)가 INSTALLED_APPS에 특별히 기입하지않고도 app을 사용할수 있게 하는 것. 또다른 하나는 INSTALLED_APPS에 AppConfig를 extends한 subclass까지의 경로를 . path형태로 직접 입력하는 것이다. 결과적으로 두가지 방법 모두 AppConfig subclass를 거쳐 가게 된다. 

The recommended convention is to put the configuration class in a submodule of the application called apps. However, this isn’t enforced by Django.

You must include the name attribute for Django to determine which application this configuration applies to. You can define any attributes documented in the AppConfig API reference.


If your code imports the application registry in an application’s __init__.py, the name apps will clash with the apps submodule. The best practice is to move that code to a submodule and import it. A workaround is to import the registry under a different name:

from django.apps import apps as django_apps

For application users

If you’re using “Rock ’n’ roll” in a project called anthology, but you want it to show up as “Jazz Manouche” instead, you can provide your own configuration:

# anthology/apps.py

from rock_n_roll.apps import RockNRollConfig

class JazzManoucheConfig(RockNRollConfig):
    verbose_name = "Jazz Manouche"

# anthology/settings.py

    # ...

Again, defining project-specific configuration classes in a submodule called apps is a convention, not a requirement.

Application configuration




Application configuration objects store metadata for an application. Some attributes can be configured in AppConfig subclasses. Others are set by Django and read-only.

Configurable attributes



Full Python path to the application, e.g. 'django.contrib.admin'.

This attribute defines which application the configuration applies to. It must be set in all AppConfig subclasses.

It must be unique across a Django project.



Short name for the application, e.g. 'admin'

This attribute allows relabeling an application when two applications have conflicting labels. It defaults to the last component of name. It should be a valid Python identifier.

It must be unique across a Django project.



Human-readable name for the application, e.g. “Administration”.

This attribute defaults to label.title().



Filesystem path to the application directory, e.g. '/usr/lib/pythonX.Y/dist-packages/django/contrib/admin'.

In most cases, Django can automatically detect and set this, but you can also provide an explicit override as a class attribute on your AppConfig subclass. In a few situations this is required; for instance if the app package is a namespace package with multiple paths.

Read-only attributes



Root module for the application, e.g. <module 'django.contrib.admin' from 'django/contrib/admin/__init__.py'>.



Module containing the models, e.g. <module 'django.contrib.admin.models' from 'django/contrib/admin/models.py'>.

It may be None if the application doesn’t contain a models module. Note that the database related signals such as pre_migrate and post_migrate are only emitted for applications that have a models module.






Returns an iterable of Model classes for this application.

Requires the app registry to be fully populated.



(model_name, require_ready=True)


Returns the Model with the given model_name. model_name is case-insensitive.

Raises LookupError if no such model exists in this application.

Requires the app registry to be fully populated unless the require_ready argument is set to False. require_ready behaves exactly as in apps.get_model().





Subclasses can override this method to perform initialization tasks such as registering signals. It is called as soon as the registry is fully populated.

Although you can’t import models at the module-level where AppConfig classes are defined, you can import them in ready(), using either an import statement or get_model().

If you’re registering model signals, you can refer to the sender by its string label instead of using the model class itself.


from django.apps import AppConfig
from django.db.models.signals import pre_save

class RockNRollConfig(AppConfig):
    # ...

    def ready(self):
        # importing model classes
        from .models import MyModel  # or...
        MyModel = self.get_model('MyModel')

        # registering signals with the model's string label
        pre_save.connect(receiver, sender='app_label.MyModel')


Although you can access model classes as described above, avoid interacting with the database in your ready() implementation. This includes model methods that execute queries (save(), delete(), manager methods etc.), and also raw SQL queries via django.db.connection. Your ready() method will run during startup of every management command. For example, even though the test database configuration is separate from the production settings, manage.py test would still execute some queries against your production database!


In the usual initialization process, the ready method is only called once by Django. But in some corner cases, particularly in tests which are fiddling with installed applications, ready might be called more than once. In that case, either write idempotent methods, or put a flag on your AppConfig classes to prevent re-running code which should be executed exactly one time.

Namespace packages as apps

Python packages without an __init__.py file are known as “namespace packages” and may be spread across multiple directories at different locations on sys.path (see PEP 420).

Django applications require a single base filesystem path where Django (depending on configuration) will search for templates, static assets, etc. Thus, namespace packages may only be Django applications if one of the following is true:

  1. The namespace package actually has only a single location (i.e. is not spread across more than one directory.)
  2. The AppConfig class used to configure the application has a path class attribute, which is the absolute directory path Django will use as the single base path for the application.

If neither of these conditions is met, Django will raise ImproperlyConfigured.

Application registry


The application registry provides the following public API. Methods that aren’t listed below are considered private and may change without notice.



Boolean attribute that is set to True after the registry is fully populated and all AppConfig.ready() methods are called.




Returns an iterable of AppConfig instances.




Returns an AppConfig for the application with the given app_label. Raises LookupError if no such application exists.




Checks whether an application with the given name exists in the registry. app_name is the full name of the app, e.g. 'django.contrib.admin'.



(app_label, model_name, require_ready=True)

Returns the Model with the given app_label and model_name. As a shortcut, this method also accepts a single argument in the form app_label.model_name. model_name is case-insensitive.

Raises LookupError if no such application or model exists. Raises ValueError when called with a single argument that doesn’t contain exactly one dot.

Requires the app registry to be fully populated unless the require_ready argument is set to False.

Setting require_ready to False allows looking up models while the app registry is being populated, specifically during the second phase where it imports models. Then get_model() has the same effect as importing the model. The main use case is to configure model classes with settings, such as AUTH_USER_MODEL.

When require_ready is False, get_model() returns a model class that may not be fully functional (reverse accessors may be missing, for example) until the app registry is fully populated. For this reason, it’s best to leave require_ready to the default value of True whenever possible.

Initialization process

How applications are loaded

When Django starts, django.setup() is responsible for populating the application registry.




Configures Django by:

  • Loading the settings.
  • Setting up logging.
  • If set_prefix is True, setting the URL resolver script prefix to FORCE_SCRIPT_NAME if defined, or / otherwise.
  • Initializing the application registry.

This function is called automatically:

  • When running an HTTP server via Django’s WSGI support.
  • When invoking a management command.

It must be called explicitly in other cases, for instance in plain Python scripts.

The application registry is initialized in three stages. At each stage, Django processes all applications in the order of INSTALLED_APPS.

First Django imports each item in INSTALLED_APPS.

If it’s an application configuration class, Django imports the root package of the application, defined by its name attribute. If it’s a Python package, Django creates a default application configuration.

At this stage, your code shouldn’t import any models!

In other words, your applications’ root packages and the modules that define your application configuration classes shouldn’t import any models, even indirectly.

Strictly speaking, Django allows importing models once their application configuration is loaded. However, in order to avoid needless constraints on the order of INSTALLED_APPS, it’s strongly recommended not import any models at this stage.

Once this stage completes, APIs that operate on application configurations such as get_app_config() become usable.

Then Django attempts to import the models submodule of each application, if there is one.

You must define or import all models in your application’s models.py or models/__init__.py. Otherwise, the application registry may not be fully populated at this point, which could cause the ORM to malfunction.

Once this stage completes, APIs that operate on models such as get_model() become usable.

Finally Django runs the ready() method of each application configuration.


Here are some common problems that you may encounter during initialization:

AppRegistryNotReady: This happens when importing an application configuration or a models module triggers code that depends on the app registry.

For example, gettext() uses the app registry to look up translation catalogs in applications. To translate at import time, you need gettext_lazy() instead. (Using gettext() would be a bug, because the translation would happen at import time, rather than at each request depending on the active language.)

Executing database queries with the ORM at import time in models modules will also trigger this exception. The ORM cannot function properly until all models are available.

This exception also happens if you forget to call django.setup() in a standalone Python script.

ImportError: cannot import name ... This happens if the import sequence ends up in a loop.

To eliminate such problems, you should minimize dependencies between your models modules and do as little work as possible at import time. To avoid executing code at import time, you can move it into a function and cache its results. The code will be executed when you first need its results. This concept is known as “lazy evaluation”.

django.contrib.admin automatically performs autodiscovery of admin modules in installed applications. To prevent it, change your INSTALLED_APPS to contain 'django.contrib.admin.apps.SimpleAdminConfig' instead of 'django.contrib.admin'.

original source : https://youtu.be/zPVLRvpzOOU

settings 라는 폴더를 만들어 각 상황에 맞는 setting 파일을 만든다.

DJANGO_SETTINGS_MODULE 환경변수에 정의되어있는 기존의 경로를 변경한다.