Code

Changes between Version 1 and Version 2 of DjangoDocumentKoreanTranslation/authentication


Ignore:
Timestamp:
11/12/07 04:10:14 (6 years ago)
Author:
spike
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DjangoDocumentKoreanTranslation/authentication

    v1 v2  
    22 
    33 
    4 = User authentication in Django = 
    5  
    6 Django comes with a user authentication system. It handles user accounts, 
    7 groups, permissions and cookie-based user sessions. This document explains how 
    8 things work. 
    9  
    10 = Overview = 
    11  
    12 The auth system consists of: 
    13  
    14     * Users 
    15     * Permissions: Binary (yes/no) flags designating whether a user may perform 
    16       a certain task. 
    17     * Groups: A generic way of applying labels and permissions to more than one 
    18       user. 
    19     * Messages: A simple way to queue messages for given users. 
    20  
    21 = Installation = 
    22  
    23 Authentication support is bundled as a Django application in 
    24 {{{django.contrib.auth}}}. To install it, do the following: 
    25  
    26     1. Put {{{'django.contrib.auth'}}} in your {{{INSTALLED_APPS}}} setting. 
    27     2. Run the command {{{manage.py syncdb}}}. 
    28  
    29 Note that the default {{{settings.py}}} file created by 
    30 {{{django-admin.py startproject}}} includes {{{'django.contrib.auth'}}} in 
    31 {{{INSTALLED_APPS}}} for convenience. If your {{{INSTALLED_APPS}}} already contains 
    32 {{{'django.contrib.auth'}}}, feel free to run {{{manage.py syncdb}}} again; you 
    33 can run that command as many times as you'd like, and each time it'll only 
    34 install what's needed. 
    35  
    36 The {{{syncdb}}} command creates the necessary database tables, creates 
    37 permission objects for all installed apps that need 'em, and prompts you to 
    38 create a superuser account the first time you run it. 
    39  
    40 Once you've taken those steps, that's it. 
    41  
    42 = Users = 
    43  
    44 Users are represented by a standard Django model, which lives in 
    45 [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py django/contrib/auth/models.py]. 
    46  
    47  
    48 == API reference == 
    49  
    50 === Fields === 
    51  
    52 {{{User}}} objects have the following fields: 
    53  
    54     * {{{username}}} - Required. 30 characters or fewer. Alphanumeric characters 
    55       only (letters, digits and underscores). 
    56     * {{{first_name}}} - Optional. 30 characters or fewer. 
    57     * {{{last_name}}} - Optional. 30 characters or fewer. 
    58     * {{{email}}} - Optional. E-mail address. 
    59     * {{{password}}} - Required. A hash of, and metadata about, the password. 
    60       (Django doesn't store the raw password.) Raw passwords can be arbitrarily 
    61       long and can contain any character. See the "Passwords" section below. 
    62     * {{{is_staff}}} - Boolean. Designates whether this user can access the 
    63       admin site. 
    64     * {{{is_active}}} - Boolean. Designates whether this account can be used 
    65       to log in. Set this flag to {{{False}}} instead of deleting accounts. 
    66     * {{{is_superuser}}} - Boolean. Designates that this user has all permissions 
    67       without explicitly assigning them. 
    68     * {{{last_login}}} - A datetime of the user's last login. Is set to the 
    69       current date/time by default. 
    70     * {{{date_joined}}} - A datetime designating when the account was created. 
    71       Is set to the current date/time by default when the account is created. 
    72  
    73 === Methods === 
    74  
    75 {{{User}}} objects have two many-to-many fields: {{{groups}}} and 
    76 {{{user_permissions}}}. {{{User}}} objects can access their related 
    77 objects in the same way as any other [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py Django model]: 
     4= 장고의 사용자 인증 = 
     5 
     6장고는 사용자 인증 시스템을 가지고 있습니다. 사용자 계정, 그룹, 
     7허용권한(permission)과 쿠키를 기반으로 한 세션(session)을 지원합니다. 
     8 
     9= 개요 = 
     10 
     11인증 시스템은 다음으로 구성되어 있습니다.: 
     12 
     13    * 사용자 
     14    * 허용권한(permission): 작업 단위로 허용 여부를 바이너리(binary)로 구분 
     15    * 그룹: 하나 이상의 사용자에게 label과 허용권한(permission)을 부여 
     16    * 메세지: 사용자에게 메세지를 전달 
     17= 설치 = 
     18 
     19인증은 장고의 {{{django.contrib.auth}}}에 포함되어 있습니다. 설치는 
     20다음을 따르세요.: 
     21 
     22    1. {{{'django.contrib.auth'}}}을 여러분의 settings.py의 {{{INSTALLED_APPS}}}에 
     23     추가하세요. 
     24    2. {{{manage.py syncdb}}}을 실행하세요. 
     25 
     26참고로 {{{'django.contrib.auth'}}}는 {{{django-admin.py startproject}}}로 
     27자동으로 만들어지는 {{{settings.py}}}의 {{{INSTALLED_APPS}}} 항목에 
     28포함되어 있습니다. {{{INSTALLED_APPS}}}에 {{{'django.contrib.auth'}}}가 
     29이미 포함되어 있다면 {{{manage.py syncdb}}}로 몇번이든 새로 인증시스템을 
     30설치할 수 있습니다. 
     31 
     32{{{syncdb}}} 명령은 설치된 어플리케이션(installed apps)에 필요한 
     33데이터베이스 테이블을 새로 만들고 처음 실행하는 경우에 관리자 계정을 
     34추가로 만듭니다. 
     35 
     36위 과정은 한번으로 충분합니다. 
     37 
     38= 사용자 = 
     39 
     40사용자는 [http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/models.py django/contrib/auth/models.py]에 구현된 장고 모델(Django 
     41model)로 표현됩니다. 
     42 
     43 
     44== API 참고 == 
     45 
     46=== 필드(field) === 
     47 
     48{{{User}}} 객체(object)는 다음과 같은 필드(field)를 가지고 있습니다.: 
     49 
     50    * {{{username}}} - 반드시 필요. 최대 30자까지. 반드시 문자나 숫자, 
     51      '.'이나 '_' {{{first_name}}} - 추가 선택. 최대 30자까지. 
     52    * {{{last_name}}} - 추가 선택. 최대 30자까지. 
     53    * {{{email}}} - 추가 선택. 이메일 주소. 
     54    * {{{password}}} - 반드시 필요. 비밀번호를 해쉬(hash)로 저장합니다. 
     55      장고는 비밀번호를 읽을 수 있도록(raw password) 저장하지 않습니다. 
     56      비밀번호는 무한정 길어질 수 있고 어떤 글자도 포함될 수 있습니다. 
     57      아래 "Passwords" 항목을 읽어보세요. 
     58    * {{{is_staff}}} - Boolean. 관리자 사이트에 접근할 수 있는 여부 
     59    * {{{is_active}}} - Boolean. 로그인할 수 있는 여부. 사용자를 
     60      제거하는 대신 이 항목을 {{{False}}}로 설정하세요. 
     61    * {{{is_superuser}}} - Boolean. 모든 허용권한(permission)을 
     62      가지도록 합니다. 
     63    * {{{last_login}}} - 사용자가 마지막으로 로그인할 날짜와 
     64      시간(datetime). 기본으로 현재 시간(date/time)이 저장됩니다. 
     65 
     66    * {{{date_joined}}} - 사용자가 만들어진 날짜와 시간(datetime). 
     67      기본으로 현재 시간(date/time)이 저장됩니다. 
     68=== 메소드(method) === 
     69 
     70{{{User}}} 객체(object)는 두 개의 {{{many-to-many field}}}를 가집니다.: 
     71{{{groups}}}과 {{{user_permissions}}}. {{{User}}} 객체(object)는 
     72다른 [wiki:../model-api/ Django model]과 같은 방법으로 연관된 객체(object)에 
     73접근할 수 있습니다.: 
    7874{{{ 
    7975myuser.groups = [group_list] 
     
    8682myuser.user_permissions.clear() 
    8783}}} 
    88 In addition to those automatic API methods, {{{User}}} objects have the following 
    89 custom methods: 
    90  
    91     * {{{is_anonymous()}}} - Always returns {{{False}}}. This is a way of 
    92       differentiating {{{User}}} and {{{AnonymousUser}}} objects. Generally, you 
    93       should prefer using {{{is_authenticated()}}} to this method. 
    94  
    95     * {{{is_authenticated()}}} - Always returns {{{True}}}. This is a way to 
    96       tell if the user has been authenticated. This does not imply any 
    97       permissions, and doesn't check if the user is active - it only indicates 
    98       that the user has provided a valid username and password. 
    99  
    100     * {{{get_full_name()}}} - Returns the {{{first_name}}} plus the {{{last_name}}}, 
    101       with a space in between. 
    102  
    103     * {{{set_password(raw_password)}}} - Sets the user's password to the given 
    104       raw string, taking care of the password hashing. Doesn't save the 
    105       {{{User}}} object. 
    106  
    107     * {{{check_password(raw_password)}}} - Returns {{{True}}} if the given raw 
    108       string is the correct password for the user. (This takes care of the 
    109       password hashing in making the comparison.) 
    110  
    111     * {{{set_unusable_password()}}} - '''New in Django development version.''' 
    112       Marks the user as having no password set.  This isn't the same as having 
    113       a blank string for a password. {{{check_password()}}} for this user will 
    114       never return {{{True}}}. Doesn't save the {{{User}}} object. 
    115  
    116     You may need this if authentication for your application takes place 
    117     against an existing external source such as an LDAP directory. 
    118  
    119     * {{{has_usable_password()}}} - '''New in Django development version.''' 
    120     Returns {{{False}}} if {{{set_unusable_password()}}} has been called for this 
    121     user. 
    122  
    123     * {{{get_group_permissions()}}} - Returns a list of permission strings that 
    124     the user has, through his/her groups. 
    125  
    126     * {{{get_all_permissions()}}} - Returns a list of permission strings that 
    127     the user has, both through group and user permissions. 
    128  
    129     * {{{has_perm(perm)}}} - Returns {{{True}}} if the user has the specified 
    130     permission, where perm is in the format {{{"package.codename"}}}. 
    131     If the user is inactive, this method will always return {{{False}}}. 
    132  
    133     * {{{has_perms(perm_list)}}} - Returns {{{True}}} if the user has each of the 
    134     specified permissions, where each perm is in the format 
    135     {{{"package.codename"}}}. If the user is inactive, this method will 
    136     always return {{{False}}}. 
    137  
    138     * {{{has_module_perms(package_name)}}} - Returns {{{True}}} if the user has 
    139     any permissions in the given package (the Django app label). 
    140     If the user is inactive, this method will always return {{{False}}}. 
    141  
    142     * {{{get_and_delete_messages()}}} - Returns a list of {{{Message}}} objects in 
    143     the user's queue and deletes the messages from the queue. 
    144  
    145     * {{{email_user(subject, message, from_email=None)}}} - Sends an e-mail to 
    146     the user. If {{{from_email}}} is {{{None}}}, Django uses the 
    147     [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py DEFAULT_FROM_EMAIL] setting. 
    148  
    149     * {{{get_profile()}}} - Returns a site-specific profile for this user. 
    150     Raises {{{django.contrib.auth.models.SiteProfileNotAvailable}}} if the current site 
    151     doesn't allow profiles. 
    152  
    153  
    154 === Manager functions === 
    155  
    156 The {{{User}}} model has a custom manager that has the following helper functions: 
    157  
    158     * {{{create_user(username, email, password=None)}}} - Creates, saves and 
    159     returns a {{{User}}}. The {{{username}}}, {{{email}}} and {{{password}}} are set 
    160     as given, and the {{{User}}} gets {{{is_active=True}}}. 
    161  
    162     If no password is provided, {{{set_unusable_password()}}} will be called. 
    163  
    164     See _`Creating users` for example usage. 
    165  
    166     * {{{make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')}}} 
    167     Returns a random password with the given length and given string of 
    168     allowed characters. (Note that the default value of {{{allowed_chars}}} 
    169     doesn't contain letters that can cause user confusion, including 
    170     {{{1}}}, {{{I}}} and {{{0}}}). 
    171  
    172 == Basic usage == 
    173  
    174 === Creating users === 
    175  
    176 The most basic way to create users is to use the {{{create_user}}} helper 
    177 function that comes with Django: 
     84미리 정의된 이러한 메소드(method)와 함께, {{{User}}} 객체(object)는 
     85다음과 같은 특별한 메소드(method)를 가지고 있습니다. 
     86 
     87    * {{{is_anonymous()}}} - 항상 {{{False}}}를 반환합니다. 이것으로 
     88      {{{User}}}와 {{{AnonymousUser}}}를 구분할 수 있습니다. 일반적으로 
     89      {{{is_authenticated()}}}을 사용하는 것이 유리합니다. 
     90 
     91    * {{{is_authenticated()}}} - 항상 {{{True}}}를 반환합니다. 사용자가 
     92      인증을 통과했는지 말해줍니다. 단, 이 메소드(method)는 사용자의 
     93      허용권한(permission)이 아니라 사용자가 정확한 {{{username}}}과 
     94      {{{password}}}로 인증을 통과했는지만 판단합니다. 
     95 
     96    * {{{get_full_name()}}} - {{{first_name}}}과 {{{last_name}}}를 
     97      빈칸(space)으로 묶어서 가져옵니다. 
     98 
     99    * {{{set_password(raw_password)}}} - 사용자 비밀번호를 지정합니다. 
     100      {{{User}}}객체(object)에 직접 비밀번호를 저장하지 마세요. 
     101 
     102    * {{{check_password(raw_password)}}} - 주어진 사용자 비밀번호가 
     103      정확한지 검사합니다. 
     104 
     105    * {{{set_unusable_password()}}} - '''장고 개발버전에 새롭게 추가''' 
     106      비밀번호를 사용하지 않도록 합니다. 단, 이것은 {{{password}}} 
     107      필드(field)를 빈공백(blank string)으로 처리하는 것과는 다릅니다. 
     108      {{{password}}} 필드(field)에 빈 공백(blank string)으로 저장하면 
     109      {{{check_password}}}는 {{{True}}}를 반환하지 않습니다. 
     110      {{{User}}}객체(object)에 직접 저장하지 마세요. 
     111 
     112    이 방법은 LDAP 디렉토리 서비스와 같이 외부 인증시스템을 사용할 
     113    경우에 사용하세요. 
     114 
     115    * {{{has_usable_password()}}} - '''장고 개발버전에 새롭게 추가''' 
     116    {{{set_unusable_password()}}}가 설정된 사용자는 {{{False}}}를 
     117    반환합니다. 
     118 
     119    * {{{get_group_permissions()}}} - 사용자가 속한 그룹의 
     120    허용권한(permission) 리스트(list)를 반환합니다. 
     121 
     122    * {{{get_all_permissions()}}} - 사용자과 사용자의 그룹의 
     123    허용권한(permission) 리스트(list)를 반환합니다. 
     124 
     125    * {{{has_perm(perm)}}} - 사용자가 {{{"package.codename"}}}에 명시된 
     126    특정한 허용권한(permission)을 가지고 있는지 검사합니다. 
     127    {{{is_active}}}가 {{{False}}}인 경우 항상 {{{False}}}를 반환합니다. 
     128 
     129    * {{{has_perms(perm_list)}}} - {{{"package.codename"}}}에 명시된 
     130    허용권한(permission)들을 가지고 있는지 검사합니다. 
     131    {{{is_active}}}가 {{{False}}}인 경우 항상 {{{False}}}를 반환합니다. 
     132 
     133    * {{{has_module_perms(package_name)}}} - 사용자가 특정한 장고 
     134    패키지(package)과 관련된 허용권한(permission)을 가지고 있는지 
     135    검사합니다. {{{is_active}}}가 {{{False}}}인 경우 항상 {{{False}}}를 
     136    반환합니다. 
     137 
     138    * {{{get_and_delete_messages()}}} - 사용자에게 전달될 {{{Message}}} 
     139    객체(object) 리스트(list)를 큐(queue)에서 가져오고, 가져온 다음 
     140    큐(queue)에서 삭제합니다. 
     141 
     142    * {{{email_user(subject, message, from_email=None)}}} - 사용자에게 
     143    메일 메세지를 보냅니다. {{{from_email}}}항목이 {{{None}}}일 경우에는 
     144    [wiki:../settings/#default-from-email DEFAULT_FROM_EMAIL] 설정이 사용됩니다. 
     145 
     146    * {{{get_profile()}}} - 사용자의 사이트 프로필(site-specifi 
     147    profile)을 가져옵니다. 사이트의 프로필이 없을 때는 
     148    {{{django.contrib.auth.models.SiteProfileNotAvailable}}} 
     149    예외(Exception)가 발생합니다. 
     150 
     151 
     152=== 관리 함수(function)들 === 
     153 
     154{{{User}}}모델(model)은 유용한 함수(function)들을 가지고 있습니다. 
     155 
     156    * {{{create_user(username, email, password=None)}}} - 사용자를 
     157    만들고 {{{User}}}객체(object)를 반환합니다. 만들어진 사용자는 
     158    {{{is_active=True}}}로 지정됩니다. 
     159 
     160    비밀번호가 주어지지 않는 경우에 {{{set_unusable_password()}}} 
     161    메소드(method)가 호출됩니다. 
     162 
     163    [wiki: DjangoDocumentKoreanTranslation/authentication#사용자 만들기 사용자 만들기]에서 예제를 참고하세요. 
     164 
     165   * {{{make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')}}} 
     166     주어진 길이와 글자들로 임의의 비밀번호를 만듭니다. (참고로 
     167     기본으로 지정된 {{{allowed_chars}}}에는 {{{1}}}, {{{I}}} and {{{0}}}와 
     168     같은 햇갈리는 글자들은 제외되었습니다.) 
     169== 기본적인 사용법 == 
     170 
     171=== 사용자 만들기 === 
     172 
     173일반적으로 {{{create_user}}} 함수(function)를 사용해서 사용자를 
     174만듭니다.: 
    178175{{{ 
    179176>>> from django.contrib.auth.models import User 
    180177>>> user = User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword') 
    181178 
    182 # At this point, user is a User object that has already been saved 
    183 # to the database. You can continue to change its attributes 
    184 # if you want to change other fields. 
     179 # 여기서 사용자 객체(object)는 이미 데이터베이스에 
     180 # 저장되었습니다. 객체(object)의 속성(attribute)을 변경할 수 
     181 # 있습니다. 
    185182>>> user.is_staff = True 
    186183>>> user.save() 
    187184}}} 
    188 === Changing passwords === 
    189  
    190 Change a password with {{{set_password()}}}: 
     185=== 비밀번호 바꾸기 === 
     186 
     187{{{set_password()}}}로 비밀번호를 변경합니다.: 
    191188{{{ 
    192189>>> from django.contrib.auth.models import User 
    193190>>> u = User.objects.get(username__exact='john') 
    194 >>> u.set_password('new password') 
     191>>> u.set_password('새로운 비밀번호') 
    195192>>> u.save() 
    196193}}} 
    197 Don't set the {{{password}}} attribute directly unless you know what you're 
    198 doing. This is explained in the next section. 
    199  
    200 == Passwords == 
    201  
    202 The {{{password}}} attribute of a {{{User}}} object is a string in this format: 
     194특별한 이유가 없다면, 비밀번호를 {{{User}}}객체(object)의 {{{password}}} 
     195속성(attribute)으로 지정하는 방법으로 변경하는 것은 바람직하지 
     196않습니다. 이유는 다음 섹션에서 설명합니다. 
     197 
     198== 비밀번호 == 
     199 
     200{{{User}}}객체(object)의 {{{password}}}속성(attribute)은 다음과 같이 구성됩니다.: 
    203201{{{ 
    204202hashtype$salt$hash 
    205203}}} 
    206 That's hashtype, salt and hash, separated by the dollar-sign character. 
    207  
    208 Hashtype is either {{{sha1}}} (default), {{{md5}}} or {{{crypt}}} - the algorithm 
    209 used to perform a one-way hash of the password. Salt is a random string used 
    210 to salt the raw password to create the hash. Note that the {{{crypt}}} method is 
    211 only supported on platforms that have the standard Python {{{crypt}}} module 
    212 available, and {{{crypt}}} support is only available in the Django development 
    213 version. 
    214  
    215 For example: 
     204달러표시(dollar-sign)로 구분된 hashtype, salt 그리고 hash의 조합입니다. 
     205 
     206Hashtype은 {{{sha1}}} (기본), {{{md5}}} 혹은 {{{crypt}}} 중 하나입니다. -- 
     207비밀번호를 거꾸로 풀 수 없는 알고리즘입니다. Salt는 hash를 만드는 
     208비밀번호를 처리하는 임의의 글자(random string)들입니다. 참고로 
     209{{{crypt}}} 방법은 {{{crypt}}} 모듈을 포함하고 있는 표준 Python이 지원하는 
     210플랫폼에서만 지원되고, {{{crypt}}}는 장고 개발버전에서만 지원됩니다. 
     211 
     212예로: 
    216213{{{ 
    217214sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4 
    218215}}} 
    219 The {{{User.set_password()}}} and {{{User.check_password()}}} functions handle 
    220 the setting and checking of these values behind the scenes. 
    221  
    222 Previous Django versions, such as 0.90, used simple MD5 hashes without password 
    223 salts. For backwards compatibility, those are still supported; they'll be 
    224 converted automatically to the new style the first time {{{User.check_password()}}} 
    225 works correctly for a given user. 
    226  
    227 == Anonymous users == 
    228  
    229 {{{django.contrib.auth.models.AnonymousUser}}} is a class that implements 
    230 the {{{django.contrib.auth.models.User}}} interface, with these differences: 
    231  
    232     * {{{id}}} is always {{{None}}}. 
    233     * {{{is_staff}}} and {{{is_superuser}}} are always False. 
    234     * {{{is_active}}} is always True. 
    235     * {{{groups}}} and {{{user_permissions}}} are always empty. 
    236     * {{{is_anonymous()}}} returns {{{True}}} instead of {{{False}}}. 
    237     * {{{is_authenticated()}}} returns {{{False}}} instead of {{{True}}}. 
    238     * {{{has_perm()}}} always returns {{{False}}}. 
    239     * {{{set_password()}}}, {{{check_password()}}}, {{{save()}}}, {{{delete()}}}, 
    240     {{{set_groups()}}} and {{{set_permissions()}}} raise {{{NotImplementedError}}}. 
    241  
    242 In practice, you probably won't need to use {{{AnonymousUser}}} objects on your 
    243 own, but they're used by Web requests, as explained in the next section. 
    244  
    245 == Creating superusers == 
    246  
    247 {{{manage.py syncdb}}} prompts you to create a superuser the first time you run 
    248 it after adding {{{'django.contrib.auth'}}} to your {{{INSTALLED_APPS}}}. But if 
    249 you need to create a superuser after that via the command line, you can use the 
    250 {{{create_superuser.py}}} utility. Just run this command: 
     216{{{User.set_password()}}}와 {{{User.check_password()}}} 메소드(method)가 
     217이 값들을 처리할 수 있습니다. 
     218 
     2190.90같은 이전 장고 버전에서는 간단하게 Salt 없이 MD5가 사용됩니다. 
     220이전 버전을 위해서 이 방법도 여전히 유효합니다; 다만 
     221{{{User.check_password()}}}가 실행되면 자동으로 새로운 형식으로 
     222변경됩니다. 
     223 
     224== 익명사용자 == 
     225 
     226{{{django.contrib.auth.models.AnonymousUser}}} 
     227{{{django.contrib.auth.models.User}}}를 본받았지만 몇 가지 차이점이 있습니다.: 
     228 
     229    * {{{id}}}는 항상 {{{None}}}. 
     230    * {{{is_staff}}}와 {{{is_superuser}}}는 항상 {{{False}}}. 
     231    * {{{is_active}}}는 항상 {{{True}}}. 
     232    * {{{groups}}}와 {{{user_permissions}}}는 항상 비어있습니다(empty). 
     233    * {{{is_anonymous()}}}는 {{{True}}}. 
     234    * {{{is_authenticated()}}}는 {{{False}}}. 
     235    * {{{has_perm()}}}는 항상 {{{False}}}. 
     236    * {{{set_password()}}}, {{{check_password()}}}, {{{save()}}}, 
     237    {{{delete()}}}, {{{set_groups()}}} 그리고 {{{set_permissions()}}}는 
     238    {{{NotImplementedError}}} 예외(Exception)를 발생시킵니다. 
     239실제로 {{{AnonymousUser}}}를 필요 없을지도 모르지만, 다음 섹션에서 
     240설명하는 Web requests에서 사용됩니다. 
     241 
     242== 관리자 만들기 == 
     243 
     244settings.py의 {{{INSTALLED_APPS}}}에 {{{'django.contrib.auth'}}}를 추가한 
     245상태에서 처음 {{{manage.py syncdb}}}를 실행시키면 관리자 계정을 
     246만듭니다. 나중에 관리자 계정을 따로 만들려면 {{{create_superuser.py}}}를 
     247사용할 수 있습니다.: 
    251248{{{ 
    252249python /path/to/django/contrib/auth/create_superuser.py 
    253250}}} 
    254 Make sure to substitute {{{/path/to/}}} with the path to the Django codebase on 
    255 your filesystem. 
    256  
    257 = Authentication in Web requests = 
    258  
    259 Until now, this document has dealt with the low-level APIs for manipulating 
    260 authentication-related objects. On a higher level, Django can hook this 
    261 authentication framework into its system of [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py request objects]. 
    262  
    263 First, install the {{{SessionMiddleware}}} and {{{AuthenticationMiddleware}}} 
    264 middlewares by adding them to your {{{MIDDLEWARE_CLASSES}}} setting. See the 
    265 [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py session documentation] for more information. 
    266  
    267 Once you have those middlewares installed, you'll be able to access 
    268 {{{request.user}}} in views. {{{request.user}}} will give you a {{{User}}} object 
    269 representing the currently logged-in user. If a user isn't currently logged in, 
    270 {{{request.user}}} will be set to an instance of {{{AnonymousUser}}} (see the 
    271 previous section). You can tell them apart with {{{is_authenticated()}}}, like so: 
     251{{{/path/to/}}}를 장고를 설치한 디렉토리로 바꿔주세요. 
     252 
     253 
     254= Web requests에서 인증하기 = 
     255 
     256지금까지 이 문서는 인증과 관련된 객체(object)들을 다루는, 낮은 
     257수준(low-level)에서 API를 설명했습니다. 장고는 인증 
     258프레임워크(authentication framework)를 [wiki:../request_response/#httprequest-objects request objects]와 
     259연결시킵니다. 
     260 
     261먼저 장고의 미들웨어(middleware) 중에 {{{SessionMiddleware}}}와 
     262{{{AuthenticationMiddleware}}}를 settings.py의 {{{MIDDLEWARE_CLASSES}}}에 
     263추가합니다. 자세한 내용은 [wiki:../sessions/ session documentation]를 참고하세요. 
     264 
     265한번 이들 미들웨어(middleware)를 설치하면 뷰(views)에서 
     266{{{request.user}}}를 접근할 수 있습니다. {{{request.user}}}는 현재 
     267로그인한 사용자를 표현한 {{{User}}}객체(object)를 가리킵니다. 사용자가 
     268로그인하지 않았다면, {{{AnonymousUser}}}객체(object)를 대신 가리킵니다. 
     269(이전 섹션을 참고하세요.) 다음과 같이 {{{is_authenticated()}}}로 구분할 
     270수 있습니다.: 
    272271{{{ 
    273272if request.user.is_authenticated(): 
    274     # Do something for authenticated users. 
     273     # 인증된 사용자의 경우, 
    275274else: 
    276     # Do something for anonymous users. 
    277 }}} 
    278  
    279 == How to log a user in == 
    280  
    281 Django provides two functions in {{{django.contrib.auth}}}: {{{authenticate()}}} 
    282 and {{{login()}}}. 
    283  
    284 To authenticate a given username and password, use {{{authenticate()}}}. It 
    285 takes two keyword arguments, {{{username}}} and {{{password}}}, and it returns 
    286 a {{{User}}} object if the password is valid for the given username. If the 
    287 password is invalid, {{{authenticate()}}} returns {{{None}}}. Example: 
     275     # 인증되지 않은 사용자의 경우, 
     276}}} 
     277 
     278== 로그인시키는 방법은 == 
     279 
     280장고는 {{{django.contrib.auth}}}에서 두가지 함수(function)를 제공합니다.: 
     281{{{authenticate()}}}와 {{{login()}}}. 
     282 
     283사용자 이름과 패스워드로 인증하려면 {{{authenticate()}}} 
     284함수(function)를 사용하세요. 이 함수는 {{{username}}}와 {{{password}}}라는 
     285두가지 키워드 인수(keyword argument)를 받아서 인증에 성공할 경우 
     286{{{User}}}객체를 반환합니다. 그렇지 않으면 {{{None}}}을 반환합니다. 예를 
     287들면: 
    288288{{{ 
    289289from django.contrib.auth import authenticate 
     
    291291if user is not None: 
    292292    if user.is_active: 
    293         print "You provided a correct username and password!" 
     293        print "사용자이름과 비밀번호가 일치했습니다!" 
    294294    else: 
    295         print "Your account has been disabled!" 
     295        print "사용자 계정이 중단되었습니다!" 
    296296else: 
    297     print "Your username and password were incorrect." 
    298 }}} 
    299 To log a user in, in a view, use {{{login()}}}. It takes an {{{HttpRequest}}} 
    300 object and a {{{User}}} object. {{{login()}}} saves the user's ID in the session, 
    301 using Django's session framework, so, as mentioned above, you'll need to make 
    302 sure to have the session middleware installed. 
    303  
    304 This example shows how you might use both {{{authenticate()}}} and {{{login()}}}: 
     297    print "주어진 사용자 이름과 비밀번호가 정확하지 않습니다." 
     298}}} 
     299뷰(view)에서 사용자 로그인을 처리하려면 {{{HttpRequest}}}와 {{{User}}}를 
     300가지고 {{{login()}}} 메소드(method)를 사용하세요. {{{login()}}} 
     301메소드(method)는 장고 세션 프레임워크(session framework)를 통해서 
     302세션(session)에 사용자 ID를 저장합니다. 물론 세션 미들웨어(session 
     303middleware)를 설치했는지 확인해야합니다. 
     304 
     305아래 {{{authenticate()}}}와 {{{login()}}}를 사용하는 예를 설명합니다.: 
    305306{{{ 
    306307from django.contrib.auth import authenticate, login 
     
    313314        if user.is_active: 
    314315            login(request, user) 
    315             # Redirect to a success page. 
     316            # 인증된 사용자를 위한 페이지로 이동합니다. 
    316317        else: 
    317             # Return a 'disabled account' error message 
     318            # '중지된 사용자'라는 메세지를 표시합니다. 
    318319    else: 
    319320        # Return an 'invalid login' error message. 
    320 }}} 
    321 == Manually checking a user's password == 
    322  
    323 If you'd like to manually authenticate a user by comparing a 
    324 plain-text password to the hashed password in the database, use the 
    325 convenience function {{{django.contrib.auth.models.check_password}}}. It 
    326 takes two arguments: the plain-text password to check, and the full 
    327 value of a user's {{{password}}} field in the database to check against, 
    328 and returns {{{True}}} if they match, {{{False}}} otherwise. 
    329  
    330 == How to log a user out == 
    331  
    332 To log out a user who has been logged in via {{{django.contrib.auth.login()}}}, 
    333 use {{{django.contrib.auth.logout()}}} within your view. It takes an 
    334 {{{HttpRequest}}} object and has no return value. Example: 
     321        # 로그인되지 않았다는 에러 메세지를 표시합니다. 
     322}}} 
     323== 비밀번호를 손수 검사하는 방법 == 
     324 
     325{{{django.contrib.auth.models.check_password}}} 함수(function)를 
     326사용해서 글자로 표현된 비밀번호(plain-text password)와 데이터베이스에 
     327hash로 저장된 비밀번호(hashed password)를 손수 비교해서 사용자를 
     328인증할 수 있습니다. 두가지 인수(argument)가 필요합니다: 글자로 표현된 
     329비밀번호와 데이터베이스에 저장된 hash처리된 비밀번호. 동일한 경우 
     330{{{True}}}를 반환합니다. 그렇지 않을 경우에는 {{{False}}}. 
     331 
     332== 로그아웃시키는 방법 == 
     333 
     334{{{django.contrib.auth.login()}}}로 사용자를 로그아웃시키려면 
     335뷰(view)에서 {{{django.contrib.auth.logout()}}}를 사용하기 바랍니다. 
     336{{{HttpRequest}}}가 주어져야 합니다. 예를 들면: 
    335337{{{ 
    336338from django.contrib.auth import logout 
     
    338340def logout_view(request): 
    339341    logout(request) 
    340     # Redirect to a success page. 
    341 }}} 
    342 Note that {{{logout()}}} doesn't throw any errors if the user wasn't logged in. 
    343  
    344 == Limiting access to logged-in users == 
    345  
    346 === The raw way === 
    347  
    348 The simple, raw way to limit access to pages is to check 
    349 {{{request.user.is_authenticated()}}} and either redirect to a login page: 
     342    # 로그아웃한 사용자를 위한 페이지로 이동합니다. 
     343}}} 
     344참고로 {{{logout()}}}은 로그인하지 않은 사용자인 경우에도 
     345예외(Exception)를 발생시키지 않습니다. 
     346 
     347== 접근 제한하기 == 
     348 
     349=== 낮은 수준에서 처리하는 방법 === 
     350 
     351간단하게 {{{request.user.is_authenticated()}}}로 검사해서 원하는 로그인 
     352페이지로 이동시킬 수 있습니다.: 
    350353{{{ 
    351354from django.http import HttpResponseRedirect 
     
    356359    # ... 
    357360}}} 
    358 ...or display an error message: 
     361...에러 메세지를 표시하도록 할 수도 있습니다.: 
    359362{{{ 
    360363def my_view(request): 
     
    363366    # ... 
    364367}}} 
    365 === The login_required decorator === 
    366  
    367 As a shortcut, you can use the convenient {{{login_required}}} decorator: 
     368=== 로그인한 사용자를 체크하는 decorator === 
     369 
     370간단하게 사용하기 위해서 {{{login_required}}} decorator를 사용할 수 
     371있습니다.: 
    368372{{{ 
    369373from django.contrib.auth.decorators import login_required 
     
    373377my_view = login_required(my_view) 
    374378}}} 
    375 Here's an equivalent example, using the more compact decorator syntax 
    376 introduced in Python 2.4: 
     379Python 2.4부터 지원하는 decorator를 사용해서 좀더 간단하게 표시할 수 
     380있습니다.: 
    377381{{{ 
    378382from django.contrib.auth.decorators import login_required 
     
    382386    # ... 
    383387}}} 
    384 In the Django development version, {{{login_required}}} also takes an optional 
    385 {{{redirect_field_name}}} parameter. Example: 
     388장고 개발버전에서는 {{{login_required}}} decorator는 
     389{{{redirect_field_name}}}이라는 키워드 인수(keyword argument)를 지정할 
     390수 있습니다.: 
    386391{{{ 
    387392from django.contrib.auth.decorators import login_required 
     
    391396my_view = login_required(redirect_field_name='redirect_to')(my_view) 
    392397}}} 
    393 Again, an equivalent example of the more compact decorator syntax introduced in Python 2.4: 
     398Python 2.4에서 decorator를 사용한 좀더 간략한 표현을 사용할 수 
     399있습니다.: 
    394400{{{ 
    395401from django.contrib.auth.decorators import login_required 
     
    399405    # ... 
    400406}}} 
    401 {{{login_required}}} does the following: 
    402  
    403     * If the user isn't logged in, redirect to {{{settings.LOGIN_URL}}} 
    404     ({{{/accounts/login/}}} by default), passing the current absolute URL 
    405     in the query string as {{{next}}} or the value of {{{redirect_field_name}}}. 
    406     For example: 
     407{{{login_required}}}는 다음과 같은 역할을 합니다.: 
     408 
     409    * 로그인에 실패하면, {{{settings.LOGIN_URL}}}으로 
     410    이동(redirect)합니다. 이때 이 URL에는 query string으로 {{{next}}}를 
     411    이름으로 하는 {{{redirect_field_name}}}을 값으로 함께 가지게 
     412    됩니다. 
     413 
     414    예를 들면: 
    407415    {{{/accounts/login/?next=/polls/3/}}}. 
    408     * If the user is logged in, execute the view normally. The view code is 
    409     free to assume the user is logged in. 
    410  
    411 Note that you'll need to map the appropriate Django view to {{{settings.LOGIN_URL}}}. 
    412 For example, using the defaults, add the following line to your URLconf: 
     416 
     417    * 사용자가 정상적으로 로그인하면, 뷰(view)가 실행됩니다. 
     418    뷰(view)의 코드는 사용자가 로그인했다고 가정합니다. 
     419 
     420 
     421그리고 {{{settings.LOGIN_URL}}}에 설정된 뷰(view)를 지정해야 합니다. 
     422예를 들면 URLconf에 다음을 추가하세요.: 
    413423{{{ 
    414424(r'^accounts/login/$', 'django.contrib.auth.views.login'), 
    415425}}} 
    416 Here's what {{{django.contrib.auth.views.login}}} does: 
    417  
    418     * If called via {{{GET}}}, it displays a login form that POSTs to the same 
    419     URL. More on this in a bit. 
    420  
    421     * If called via {{{POST}}}, it tries to log the user in. If login is 
    422     successful, the view redirects to the URL specified in {{{next}}}. If 
    423     {{{next}}} isn't provided, it redirects to {{{settings.LOGIN_REDIRECT_URL}}} 
    424     (which defaults to {{{/accounts/profile/}}}). If login isn't successful, 
    425     it redisplays the login form. 
    426  
    427 It's your responsibility to provide the login form in a template called 
    428 {{{registration/login.html}}} by default. This template gets passed three 
    429 template context variables: 
    430  
    431     * {{{form}}}: A {{{FormWrapper}}} object representing the login form. See the 
    432     [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py forms documentation] for more on {{{FormWrapper}}} objects. 
    433     * {{{next}}}: The URL to redirect to after successful login. This may contain 
    434     a query string, too. 
    435     * {{{site_name}}}: The name of the current {{{Site}}}, according to the 
    436     {{{SITE_ID}}} setting. If you're using the Django development version and 
    437     you don't have the site framework installed, this will be set to the 
    438     value of {{{request.META['SERVER_NAME']}}}. For more on sites, see the 
    439     [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py site framework docs]. 
    440  
    441 If you'd prefer not to call the template {{{registration/login.html}}}, you can 
    442 pass the {{{template_name}}} parameter via the extra arguments to the view in 
    443 your URLconf. For example, this URLconf line would use {{{myapp/login.html}}} 
    444 instead: 
     426{{{django.contrib.auth.views.login}}}가 하는 역할은: 
     427 
     428    * {{{GET}}} 방식으로 호출하면 그냥 로그인 폼(form)을 보여줍니다. 
     429    * {{{POST}}} 방식으로 호출하면, 로그인을 시도합니다. 로그인에 
     430    성공하면 뷰(view)는 {{{next}}}에 지정된 URL로 이동(redirect)합니다. 
     431    {{{next}}}가 지정되어 있지 않으면 
     432    {{{settings.LOGIN_REDIRECT_URL}}}로 이동합니다. (기본값은 
     433    {{{/accounts/profile/}}}) 로그인에 실패하면 다시 로그인 페이지로 
     434    이동합니다. 
     435 
     436기본으로 정해진 {{{registration/login.html}}}은 직접 구현해야 합니다. 이 
     437템플릿(template)은 세가지 context 변수를 받습니다. 
     438 
     439    * {{{form}}}: 로그인 폼(form)을 표현하는 
     440    {{{FormWrapper}}}객체(object). {{{FormWrapper}}}에 대해서는 
     441    [wiki:../forms/ forms documentation] 참고하세요. 
     442    * {{{next}}}: 로그인에 성공한 뒤에 이동할 URL. query string도 포함할 
     443    수 있습니다. 
     444    * {{{site_name}}}: 현재 {{{SITE_ID}}}를 참조한 {{{Site}}}의 이름. 장고 
     445    개발버전을 사용하고 사이트 프레임워크(site framework)를 사용하지 
     446    않는다면, {{{request.META['SERVER_NAME']}}}의 값이 사용됩니다. 
     447    사이트(site)에 관해서는 [wiki:../sites/ site framework docs]를 참고하세요. 
     448 
     449{{{registration/login.html}}} 대신 템플릿(template)을 지정하고 싶으면, 
     450URLconf를 설정할 때 뷰(view)에 {{{template_name}}}을 인수(argument)로 
     451지정할 수 있습니다. 예를 들면 {{{myapp/login.html}}}을 사용하고 싶다면: 
    445452{{{ 
    446453(r'^accounts/login/$', 'django.contrib.auth.views.login', {'template_name': 'myapp/login.html'}), 
    447454}}} 
    448 Here's a sample {{{registration/login.html}}} template you can use as a starting 
    449 point. It assumes you have a {{{base.html}}} template that defines a {{{content}}} 
    450 block: 
     455{{{registration/login.html}}} 템플릿(template) 예입니다. 여기서는 
     456{{{base.html}}} 템플릿(template)을 content 블록(content block)으로 
     457사용한다고 설정했습니다.: 
    451458{{{ 
    452459{% extends "base.html" %} 
     
    455462 
    456463{% if form.has_errors %} 
    457 <p>Your username and password didn't match. Please try again.</p> 
     464<p>사용자 이름과 비밀번호를 지정하세요.</p> 
    458465{% endif %} 
    459466 
    460467<form method="post" action="."> 
    461468<table> 
    462 <tr><td><label for="id_username">Username:</label></td><td>{{ form.username }}</td></tr> 
    463 <tr><td><label for="id_password">Password:</label></td><td>{{ form.password }}</td></tr> 
     469<tr><td><label for="id_username">사용자 이름:</label></td><td>{{ form.username }}</td></tr> 
     470<tr><td><label for="id_password">비밀번호:</label></td><td>{{ form.password }}</td></tr> 
    464471</table> 
    465472 
    466 <input type="submit" value="login" /> 
     473<input type="submit" value="로그인" /> 
    467474<input type="hidden" name="next" value="{{ next }}" /> 
    468475</form> 
     
    471478}}} 
    472479 
    473 == Other built-in views == 
    474  
    475 In addition to the {{{login}}} view, the authentication system includes a 
    476 few other useful built-in views: 
     480== 이외에 다른 뷰(view)들 == 
     481 
     482{{{login}}} 뷰(view) 이외에 인증 시스템에는 몇가지 뷰(view)들을 추가로 
     483제공하고 있습니다. 
    477484 
    478485=== {{{django.contrib.auth.views.logout}}} === 
    479486 
    480 '''Description''': 
    481  
    482 Logs a user out. 
    483  
    484 '''Optional arguments''': 
    485  
    486     * {{{template_name}}}: The full name of a template to display after 
    487     logging the user out. This will default to 
    488     {{{registration/logged_out.html}}} if no argument is supplied. 
    489  
    490 '''Template context''': 
    491  
    492     * {{{title}}}: The string "Logged out", localized. 
     487'''설명''': 
     488 
     489사용자를 로그아웃시킵니다. 
     490 
     491'''추가 인수(argument)''': 
     492 
     493    * {{{template_name}}}: 로그아웃시킨 다음 사용할 템플릿(template)의 
     494    전체 이름. 지정하지 않으면 {{{registration/logged_out.html}}}이 
     495    기본으로 사용됩니다. 
     496 
     497'''템플릿(template) context''': 
     498 
     499    * {{{title}}}: "Logged out"(언어설정에 따라 번역됩니다). 
    493500 
    494501=== {{{django.contrib.auth.views.logout_then_login}}} === 
    495502 
    496 '''Description''': 
    497  
    498 Logs a user out, then redirects to the login page. 
    499  
    500 '''Optional arguments''': 
    501  
    502     * {{{login_url}}}: The URL of the login page to redirect to. This 
    503     will default to {{{settings.LOGIN_URL}}} if not supplied. 
     503'''설명''': 
     504 
     505로그아웃시킨 다음, 로그인 페이지로 이동(redirect)합니다. 
     506 
     507'''추가 인수(argument)''': 
     508 
     509    * {{{login_url}}}: 이동할 로그인 페이지의 URL. 지정하지 않으면 
     510    기본으로 {{{settings.LOGIN_URL}}}을 사용합니다. 
    504511 
    505512=== {{{django.contrib.auth.views.password_change}}} === 
    506513 
    507 '''Description''': 
    508  
    509 Allows a user to change their password. 
    510  
    511 '''Optional arguments''': 
    512  
    513     * {{{template_name}}}: The full name of a template to use for 
    514     displaying the password change form. This will default to 
    515     {{{registration/password_change_form.html}}} if not supplied. 
    516  
    517 '''Template context''': 
    518  
    519     * {{{form}}}: The password change form. 
     514'''설명''': 
     515 
     516사용자가 패스워드를 변경할 수 있는 페이지를 제공합니다. 
     517 
     518'''추가 인수(argument)''': 
     519 
     520    * {{{template_name}}}: 패스워드를 변경할 수 있는 폼(form)을 포함한 
     521    템플릿(template) 이름을 지정합니다. 따로 지정하지 않으면 
     522    {{{registration/password_change_form.html}}}을 사용합니다. 
     523 
     524'''템플릿(template) context''': 
     525 
     526    * {{{form}}}: 패스워드 변경에 필요한 폼(form). 
    520527 
    521528=== {{{django.contrib.auth.views.password_change_done}}} === 
    522529 
    523 '''Description''': 
    524  
    525 The page shown after a user has changed their password. 
    526  
    527 '''Optional arguments''': 
    528  
    529     * {{{template_name}}}: The full name of a template to use. This will 
    530     default to {{{registration/password_change_done.html}}} if not 
    531     supplied. 
     530'''설명''': 
     531 
     532사용자 패스워드를 변경한 다음 보게될 페이지. 
     533 
     534'''추가 인수(argument)''': 
     535 
     536    * {{{template_name}}}: 사용할 템플릿(template) 전체 이름. 지정하지 
     537    않으면 {{{registration/password_change_done.html}}}을 사용합니다. 
    532538 
    533539=== {{{django.contrib.auth.views.password_reset}}} === 
    534540 
    535 '''Description''': 
    536  
    537 Allows a user to reset their password, and sends them the new password 
    538 in an email. 
    539  
    540 '''Optional arguments''': 
    541  
    542     * {{{template_name}}}: The full name of a template to use for 
    543     displaying the password reset form. This will default to 
    544     {{{registration/password_reset_form.html}}} if not supplied. 
    545  
    546     * {{{email_template_name}}}: The full name of a template to use for 
    547     generating the email with the new password. This will default to 
    548     {{{registration/password_reset_email.html}}} if not supplied. 
    549  
    550 '''Template context''': 
    551  
    552     * {{{form}}}: The form for resetting the user's password. 
     541'''설명''': 
     542 
     543사용자가 패스워드를 초기화할 수 있도록 합니다. 새로운 비밀번호는 
     544장고에서 지정하고 새 비밀번호는 이메일로 전달합니다. 
     545 
     546'''추가 인수(argument)''': 
     547 
     548    * {{{template_name}}}: 사용할 템플릿(template) 전체 이름. 따로 
     549    지정하지 않으면 {{{registration/password_reset_form.html}}}를 
     550    사용합니다. 
     551 
     552    * {{{email_template_name}}}: 사용할 템플릿(template) 전체 이름. 따로 
     553    지정하지 않으면 {{{registration/password_reset_email.html}}}를 
     554    사용합니다. 
     555 
     556'''템플릿(template) context''': 
     557 
     558    * {{{form}}}: 패스워드 초기화에 사용될 폼(form). 
    553559 
    554560=== {{{django.contrib.auth.views.password_reset_done}}} === 
    555561 
    556 '''Description''': 
    557  
    558 The page shown after a user has reset their password. 
    559  
    560 '''Optional arguments''': 
    561  
    562     * {{{template_name}}}: The full name of a template to use. This will 
    563     default to {{{registration/password_reset_done.html}}} if not 
    564     supplied. 
     562'''설명''': 
     563 
     564패스워드를 초기화하고나서 보여줄 페이지 
     565 
     566'''추가 인수(argument)''': 
     567 
     568     * {{{template_name}}}: 사용할 템플릿(template) 전체 이름. 따로 
     569      지정하지 않으면 {{{registration/password_reset_done.html}}}를 
     570      사용합니다. 
    565571 
    566572=== {{{django.contrib.auth.views.redirect_to_login}}} === 
    567573 
    568 '''Description''': 
    569  
    570 Redirects to the login page, and then back to another URL after a 
    571 successful login. 
    572  
    573 '''Required arguments''': 
    574  
    575     * {{{next}}}: The URL to redirect to after a successful login. 
    576  
    577 '''Optional arguments''': 
    578  
    579     * {{{login_url}}}: The URL of the login page to redirect to. This 
    580     will default to {{{settings.LOGIN_URL}}} if not supplied. 
    581  
    582 == Built-in manipulators == 
    583  
    584 If you don't want to use the built-in views, but want the convenience 
    585 of not having to write manipulators for this functionality, the 
    586 authentication system provides several built-in manipulators: 
    587  
    588     * {{{django.contrib.auth.forms.AdminPasswordChangeForm}}}: A 
    589     manipulator used in the admin interface to change a user's 
    590     password. 
    591  
    592     * {{{django.contrib.auth.forms.AuthenticationForm}}}: A manipulator 
    593     for logging a user in. 
    594  
    595     * {{{django.contrib.auth.forms.PasswordChangeForm}}}: A manipulator 
    596     for allowing a user to change their password. 
    597  
    598     * {{{django.contrib.auth.forms.PasswordResetForm}}}: A manipulator 
    599     for resetting a user's password and emailing the new password to 
    600     them. 
    601  
    602     * {{{django.contrib.auth.forms.UserCreationForm}}}: A manipulator 
    603     for creating a new user. 
    604  
    605 == Limiting access to logged-in users that pass a test == 
    606  
    607 To limit access based on certain permissions or some other test, you'd do 
    608 essentially the same thing as described in the previous section. 
    609  
    610 The simple way is to run your test on {{{request.user}}} in the view directly. 
    611 For example, this view checks to make sure the user is logged in and has the 
    612 permission {{{polls.can_vote}}}: 
     574'''설명''': 
     575 
     576로그인페이지로 이동(redirect)시킵니다. 로그인 이후 다시 다른 URL로 
     577이동시킵니다. 
     578 
     579'''필요한 인수(argument)''': 
     580 
     581    * {{{next}}}: 로그인에 성공한 뒤에 이동(redirect)할 페이지 URL 
     582 
     583'''추가 인수(argument)''': 
     584 
     585    * {{{login_url}}}: 이동할 로그인 페이지의 URL. 따로 지정하지 않으면 
     586    {{{settings.LOGIN_URL}}}을 사용합니다. 
     587 
     588== 기본으로 사용할 수 있는 폼(form) == 
     589 
     590위에 설명한 인증과 관련된 뷰(view)를 사용하지 않으면서 장고가 
     591제공하는 인증과 관련된 폼(form)을 그대로 사용하고 싶다면 아래 장고에서 
     592제공하는 폼(form)들이 있습니다.: 
     593 
     594    * {{{django.contrib.auth.forms.AdminPasswordChangeForm}}}: 관리자 
     595    화면에서 사용하는 사용자 비밀번호를 변경할 수 있는 폼(form) 
     596 
     597    * {{{django.contrib.auth.forms.AuthenticationForm}}}: 사용자 
     598    로그인에 사용하는 폼(form) 
     599 
     600    * {{{django.contrib.auth.forms.PasswordChangeForm}}}: 사용자가 
     601    패스워드를 변경할 수 있도록 하는 폼(form) 
     602 
     603    * {{{django.contrib.auth.forms.PasswordResetForm}}}: 사용자 비밀번호 
     604    초기화에 사용하는 폼(form) 
     605 
     606    * {{{django.contrib.auth.forms.UserCreationForm}}}: 새로운 사용자를 
     607    만드는 폼(form) 
     608 
     609== 로그인된 사용자 접근 제한하기 == 
     610 
     611허용권한(permission)에 의해서 접근을 제하는 방법은 이전 섹션에서 
     612설명한 것과 다르지 않습니다. 
     613 
     614간단하게 뷰(view)에서 {{{request.user}}}를 가지고 검사할 수 있습니다. 
     615예를 들어서 아래 뷰(view)는 사용자가 로그인되었는지, 
     616{{{poll.can_vote}}}라는 허용권한(permission)을 가지고 있는지 검사합니다.: 
    613617{{{ 
    614618def my_view(request): 
    615619    if not (request.user.is_authenticated() and request.user.has_perm('polls.can_vote')): 
    616         return HttpResponse("You can't vote in this poll.") 
    617     # ... 
    618 }}} 
    619 As a shortcut, you can use the convenient {{{user_passes_test}}} decorator: 
     620        return HttpResponse("투표할 수 없습니다.") 
     621    # ... 
     622}}} 
     623더 간단하게 {{{user_passes_test}}} decorator를 사용할 수 있습니다.: 
    620624{{{ 
    621625from django.contrib.auth.decorators import user_passes_test 
     
    625629my_view = user_passes_test(lambda u: u.has_perm('polls.can_vote'))(my_view) 
    626630}}} 
    627 We're using this particular test as a relatively simple example. However, if 
    628 you just want to test whether a permission is available to a user, you can use 
    629 the {{{permission_required()}}} decorator, described later in this document. 
    630  
    631 Here's the same thing, using Python 2.4's decorator syntax: 
     631간단한 예를 들었습니다. 조금 뒤에 허용권한(permission) 여부만 검사할 
     632수 있는 decorator를 말씀드립니다. 
     633 
     634Python 2.4 이상에서는 decorator를 사용할 수 있습니다.: 
    632635{{{ 
    633636from django.contrib.auth.decorators import user_passes_test 
     
    637640    # ... 
    638641}}} 
    639 {{{user_passes_test}}} takes a required argument: a callable that takes a 
    640 {{{User}}} object and returns {{{True}}} if the user is allowed to view the page. 
    641 Note that {{{user_passes_test}}} does not automatically check that the {{{User}}} 
    642 is not anonymous. 
    643  
    644 {{{user_passes_test()}}} takes an optional {{{login_url}}} argument, which lets you 
    645 specify the URL for your login page ({{{settings.LOGIN_URL}}} by default). 
    646  
    647 Example in Python 2.3 syntax: 
     642{{{user_passes_test}}}는 인수(argument)를 필요로 합니다: {{{User}}} 
     643객체(object)를 인수(argument)로 받아서 허용권한(permission)이 있으면 
     644{{{True}}}를 반환하는 함수(function)입니다. {{{user_passes_test}}}은 
     645{{{User}}}객체(object)를 직접 검사하지 않습니다. 
     646 
     647{{{user_passes_test()}}}는 또한 {{{login_url}}}을 인수(argument)로 
     648받습니다. 반환되는 결과에 따라서 이동할 로그인 페이지URL을 지정할 수 
     649있습니다. 지정하지 않으면{{{settings.LOGIN_URL}}}이 사용됩니다. 
     650 
     651Python 2.3에서는: 
    648652{{{ 
    649653from django.contrib.auth.decorators import user_passes_test 
     
    653657my_view = user_passes_test(lambda u: u.has_perm('polls.can_vote'), login_url='/login/')(my_view) 
    654658}}} 
    655 Example in Python 2.4 syntax: 
     659Python 2.4에서는: 
    656660{{{ 
    657661from django.contrib.auth.decorators import user_passes_test 
     
    661665    # ... 
    662666}}} 
    663 === The permission_required decorator === 
    664  
    665 It's a relatively common task to check whether a user has a particular 
    666 permission. For that reason, Django provides a shortcut for that case: the 
    667 {{{permission_required()}}} decorator. Using this decorator, the earlier example 
    668 can be written as: 
     667=== permission_required decorator === 
     668 
     669앞서 설명한 대로 {{{permission_required()}}} decorator는 사용자가 어떤 
     670허용권한(permission)을 갖고 있는지 검사하는 기본적인 방법입니다.: 
    669671{{{ 
    670672from django.contrib.auth.decorators import permission_required 
     
    674676my_view = permission_required('polls.can_vote')(my_view) 
    675677}}} 
    676 Note that {{{permission_required()}}} also takes an optional {{{login_url}}} 
    677 parameter. Example: 
     678{{{permission_required()}}}는 추가로 {{{login_url}}}을 인수(argument)로 
     679받습니다. 예를 들어서: 
    678680{{{ 
    679681from django.contrib.auth.decorators import permission_required 
     
    683685my_view = permission_required('polls.can_vote', login_url='/loginpage/')(my_view) 
    684686}}} 
    685 As in the {{{login_required}}} decorator, {{{login_url}}} defaults to 
    686 {{{settings.LOGIN_URL}}}. 
    687  
    688 == Limiting access to generic views == 
    689  
    690 To limit access to a [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py generic view], write a thin wrapper around the view, 
    691 and point your URLconf to your wrapper instead of the generic view itself. 
    692 For example: 
     687{{{login_required}}} decorator처럼 {{{login_url}}}도 따로 지정하지 않으면 
     688{{{settings.LOGIN_URL}}}이 기본으로 사용됩니다. 
     689 
     690== 일반적인 뷰(view)에서 접근 제한하기 == 
     691 
     692일반적인 뷰(view)([wiki:../generic_views/ generic view])에서 접근을 제한을 제한하려면 
     693뷰(view)을 처리하는 함수(function)를 만들고 URLconf에 원래 뷰(view) 
     694대신 함수(function)를 지정해줍니다. 예를 들어서: 
    693695{{{ 
    694696from django.views.generic.date_based import object_detail 
     
    699701}}} 
    700702 
    701 = Permissions = 
    702  
    703 Django comes with a simple permissions system. It provides a way to assign 
    704 permissions to specific users and groups of users. 
    705  
    706 It's used by the Django admin site, but you're welcome to use it in your own 
    707 code. 
    708  
    709 The Django admin site uses permissions as follows: 
    710  
    711     * Access to view the "add" form and add an object is limited to users with 
    712     the "add" permission for that type of object. 
    713     * Access to view the change list, view the "change" form and change an 
    714     object is limited to users with the "change" permission for that type of 
    715     object. 
    716     * Access to delete an object is limited to users with the "delete" 
    717     permission for that type of object. 
    718  
    719 Permissions are set globally per type of object, not per specific object 
    720 instance. For example, it's possible to say "Mary may change news stories," but 
    721 it's not currently possible to say "Mary may change news stories, but only the 
    722 ones she created herself" or "Mary may only change news stories that have a 
    723 certain status, publication date or ID." The latter functionality is something 
    724 Django developers are currently discussing. 
    725  
    726 == Default permissions == 
    727  
    728 Three basic permissions - add, change and delete - are automatically created 
    729 for each Django model that has a {{{class Admin}}} set. Behind the scenes, these 
    730 permissions are added to the {{{auth_permission}}} database table when you run 
    731 {{{manage.py syncdb}}}. 
    732  
    733 Note that if your model doesn't have {{{class Admin}}} set when you run 
    734 {{{syncdb}}}, the permissions won't be created. If you initialize your database 
    735 and add {{{class Admin}}} to models after the fact, you'll need to run 
    736 {{{manage.py syncdb}}} again. It will create any missing permissions for 
    737 all of your installed apps. 
    738  
    739 == Custom permissions == 
    740  
    741 To create custom permissions for a given model object, use the {{{permissions}}} 
    742 [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py model Meta attribute]. 
    743  
    744 This example model creates three custom permissions: 
     703= 허용권한(permission) = 
     704 
     705장고는 간단한 허용권한(permission) 시스템을 갖고 있습니다. 사용자와 
     706사용자의 그룹에 허용권한(permission)을 할당하는 방법을 제공합니다. 
     707 
     708장고 관리자 사이트에서 주로 사용되지만, 여러분의 사이트에 
     709적용해보세요. 
     710 
     711장고 관리 사이트는 아래와 같이 허용권한(permission)을 사용합니다. 
     712 
     713    * 폼(form)을 통해서 새로운 객체(object)를 추가할 때 객체(object) 
     714    type에 대한 "add"(더하기) 허용권한(permission)으로 뷰(view)에 
     715    대한 사용자 접근을 제한합니다. 
     716 
     717    * 폼(form)을 통해서 객체(object)의 속성(attribute)을 변경할 때 
     718    객체(object) type에 대한 "change"(바꾸기) 
     719    허용권한(permission)으로 뷰(view)에 대한 사용자 접근을 
     720    제한합니다. 
     721 
     722    * 폼(form)을 통해서 객체(object)를 지울 때 객체(object) type에 대한 
     723    "delete"(지우기) 허용권한(permission)으로 뷰(view)에 대한 사용자 
     724    접근을 제한합니다. 
     725 
     726허용권한(permission)은 특정한 객체(object)에 대해서가 아니라, 
     727객체(object) 타입 별로 전역적(globally)으로 지정됩니다. 예를 들어서 
     728장고에서는 이렇게 말할 수 있습니다. "영희는 새로운 기사를 바꿀 수 
     729있습니다." 하지만 "영희는 자기가 쓴 새로운 기사만 바꿀 수 있습니다." 
     730혹은 "영희는 특정한 기사 상태나 공개여부 혹은 기사 번호의 새로운 
     731기사를 바꿀 수 있습니다."라는 식으로는 불가능합니다. 이 부분은 장고 
     732개발자들끼리 얘기 중입니다. 
     733 
     734== 허용권한(permission)의 기본 == 
     735 
     736세가지 기본 허용권한(permission) - 더하기(add), 바꾸기(change), 
     737지우기(delete) --는 {{{class Admin}}}이 지정된 장고 모델(model)을 만들면 
     738자동으로 부여됩니다. 좀 더 자세히 설명하자면, {{{manage.py syncdb}}}가 
     739실행되면 데이터베이스에는 {{{auth_permission}}} 테이블이 생성되는데 이 
     740테이블에 해당 모델(model)에 대한 허용권한(permission)이 저장됩니다. 
     741 
     742물론 {{{class Admin}}}을 모델(model)에 지정하지 않은 채로 {{{syncdb}}}를 
     743실행하면 허용권한(permission)은 부여되지 않습니다. {{{class Admin}}}를 
     744모델(model)에 추가하고 다시 {{{manage.py syncdb}}}를 실행하세요. 그러면 
     745빠졌던 허용권한(permission)이 새로 부여됩니다. 
     746 
     747== 개발자가 정의한 허용권한(permission) == 
     748 
     749[wiki:../model-api/#meta-options model Meta attribute]에 {{{permissions}}}을 추가해서 개발자가 직접 
     750정의한 허용권한(permission)을 사용할 수 있습니다. 
     751 
     752아래 모델(model)은 세가지 허용권한(permission)을 만들었습니다.: 
    745753{{{ 
    746754class USCitizen(models.Model): 
     
    753761        ) 
    754762}}} 
    755 The only thing this does is create those extra permissions when you run 
    756 {{{syncdb}}}. 
    757  
    758  
    759 == API reference == 
    760  
    761 Just like users, permissions are implemented in a Django model that lives in 
    762 [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py django/contrib/auth/models.py]. 
    763  
    764  
    765 === Fields === 
    766  
    767 {{{Permission}}} objects have the following fields: 
    768  
    769     * {{{name}}} - Required. 50 characters or fewer. Example: {{{'Can vote'}}}. 
    770     * {{{content_type}}} - Required. A reference to the {{{django_content_type}}} 
    771     database table, which contains a record for each installed Django model. 
    772     * {{{codename}}} - Required. 100 characters or fewer. Example: {{{'can_vote'}}}. 
    773  
    774 === Methods === 
    775  
    776 {{{Permission}}} objects have the standard data-access methods like any other 
    777 [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py Django model]. 
    778  
    779 = Authentication data in templates = 
    780  
    781 The currently logged-in user and his/her permissions are made available in the 
    782 [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py template context] when you use {{{RequestContext}}}. 
    783  
    784  Technicality:: 
    785  
    786    Technically, these variables are only made available in the template context 
    787    if you use {{{RequestContext}}} *and* your {{{TEMPLATE_CONTEXT_PROCESSORS}}} 
    788    setting contains {{{"django.core.context_processors.auth"}}}, which is default. 
    789    For more, see the [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py RequestContext docs]. 
    790  
    791  
    792 == Users == 
    793  
    794 The currently logged-in user, either a {{{User}}} instance or an{{{AnonymousUser}}} 
    795 instance, is stored in the template variable {{{ {{ user }} }}}: 
     763이것도 또한 {{{syncdb}}}를 할 때 추가로 지정된 허용권한(permission)으로 
     764추가됩니다. 
     765 
     766 
     767== API 참고 == 
     768 
     769사용자 클래스(class)처럼 허용권한(permission)은 
     770[http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/models.py django/contrib/auth/models.py]이 정의하는 장고 모델(model)에서 
     771구현되어 있습니다. 
     772 
     773 
     774=== 필드(field) === 
     775 
     776{{{Permission}}}객체(object)는 아래와 같은 필드(field)를 가지고 있습니다.: 
     777 
     778    * {{{name}}} - 반드시 필요. 최대 50자까지. 예: {{{'Can vote'}}}. 
     779    * {{{content_type}}} - 반드시 필요. {{{django_content_type}}} 
     780    테이블이 정의에 따릅니다. 
     781    * {{{codename}}} - 반드시 필요. 최대 100자까지. 예: {{{'can_vote'}}}. 
     782 
     783=== 메소드(method) === 
     784 
     785{{{Permission}}}객체(object)는 다른 [wiki:../model-api/ Django model]에서처럼 데이터에 
     786접근하는 일관된 메소드(method)를 제공합니다. 
     787 
     788= 템플릿(template)에서 인증과 관련된 데이터 = 
     789 
     790{{{RequestContext}}}를 사용할 경우 현재 로그인된 사용자와 이 사용자에 
     791부여된 허용권한(permission)은 [wiki:../templates_python/ template context]를 통해서 접근할 수 
     792있습니다. 
     793 
     794 좀더 자세히:: 
     795 
     796    이 변수들은 설정(settings) 중 {{{TEMPLATE_CONTEXT_PROCESSORS}}}에 
     797    {{{"django.core.context_processors.auth"}}}를 추가하고 
     798    {{{RequestContext}}}를 사용할 경우에만 가능합니다. 자세한 내용은 
     799    [wiki:../templates_python/#subclassing-context-requestcontext RequestContext docs]를 참고하세요. 
     800 
     801 
     802 
     803== 사용자 == 
     804 
     805{{{User}}}객체(object) 혹은 {{{AnonymousUser}}}객체(object) 모두 
     806템플릿(template) 변수, {{{ {{ user }} }}}에 저장됩니다.: 
    796807{{{ 
    797808{% if user.is_authenticated %} 
    798     <p>Welcome, {{ user.username }}. Thanks for logging in.</p> 
     809    <p>안녕하세요, {{ user.username }}. 로그인하셨습니다.</p> 
    799810{% else %} 
    800     <p>Welcome, new user. Please log in.</p> 
     811    <p>안녕하세요, 로그인하세요.</p> 
    801812{% endif %} 
    802813}}} 
    803 == Permissions == 
    804  
    805 The currently logged-in user's permissions are stored in the template variable 
    806 {{{ {{ perms }} }}}. This is an instance of {{{django.core.context_processors.PermWrapper}}}, 
    807 which is a template-friendly proxy of permissions. 
    808  
    809 In the {{{ {{ perms }} }}} object, single-attribute lookup is a proxy to 
    810 {{{User.has_module_perms}}}. This example would display {{{True}}} if the logged-in 
    811 user had any permissions in the {{{foo}}} app: 
     814== 허용권한(permission) == 
     815 
     816로그인된 사용자의 허용권한(permission)은 템플릿(template) 변수, 
     817{{{ {{ perms }} }}}에 저장됩니다. {{{ {{ perms }} }}}은 
     818{{{django.core.context_processors.PermWrapper}}}의 객체(object)입니다. 
     819 
     820{{{ {{ perms }} }}}은 {{{User.has_module_perms}}}을 직접 가리킵니다. 
     821즉, 어플리케이션(app) 이름으로 허용권한(permission)을 객체(object) 
     822속성(attribute)으로 가져올 수 있습니다.: 
    812823{{{ 
    813824{{ perms.foo }} 
    814825}}} 
    815 Two-level-attribute lookup is a proxy to {{{User.has_perm}}}. This example would 
    816 display {{{True}}} if the logged-in user had the permission {{{foo.can_vote}}}: 
     826{{{User.has_perms}}}를 통해서 접근 여부를 허용권한(permission) 이름으로 
     827객체(object) 속성(attribute)으로 가져올 수 있습니다.: 
    817828{{{ 
    818829{{ perms.foo.can_vote }} 
    819830}}} 
    820 Thus, you can check permissions in template {{{ {% if %} }}} statements: 
     831다음과 같이 템플릿(template)의 {{{ {% if %} }}} 구문으로 
     832허용권한(permission)을 검사할 수 있습니다.: 
    821833{{{ 
    822834{% if perms.foo %} 
    823     <p>You have permission to do something in the foo app.</p> 
     835    <p>foo 어플리케이션에 접근할 수 있습니다.</p> 
    824836    {% if perms.foo.can_vote %} 
    825         <p>You can vote!</p> 
     837        <p>투표할 수 있습니다!</p> 
    826838    {% endif %} 
    827839    {% if perms.foo.can_drive %} 
    828         <p>You can drive!</p> 
     840        <p>운전할 수 있습니다!</p> 
    829841    {% endif %} 
    830842{% else %} 
    831     <p>You don't have permission to do anything in the foo app.</p> 
     843    <p>foo 어플리케이션에서 할 수 있는 게 없군요.</p> 
    832844{% endif %} 
    833845}}} 
    834846 
    835 = Groups = 
    836  
    837 Groups are a generic way of categorizing users so you can apply permissions, or 
    838 some other label, to those users. A user can belong to any number of groups. 
    839  
    840 A user in a group automatically has the permissions granted to that group. For 
    841 example, if the group {{{Site editors}}} has the permission 
    842 {{{can_edit_home_page}}}, any user in that group will have that permission. 
    843  
    844 Beyond permissions, groups are a convenient way to categorize users to give 
    845 them some label, or extended functionality. For example, you could create a 
    846 group {{{'Special users'}}}, and you could write code that could, say, give them 
    847 access to a members-only portion of your site, or send them members-only e-mail 
    848 messages. 
    849  
    850 = Messages = 
    851  
    852 The message system is a lightweight way to queue messages for given users. 
    853  
    854 A message is associated with a {{{User}}}. There's no concept of expiration or 
    855 timestamps. 
    856  
    857 Messages are used by the Django admin after successful actions. For example, 
    858 {{{"The poll Foo was created successfully."}}} is a message. 
    859  
    860 The API is simple: 
    861  
    862     * To create a new message, use 
    863     {{{user_obj.message_set.create(message='message_text')}}}. 
    864     * To retrieve/delete messages, use {{{user_obj.get_and_delete_messages()}}}, 
    865     which returns a list of {{{Message}}} objects in the user's queue (if any) 
    866     and deletes the messages from the queue. 
    867  
    868 In this example view, the system saves a message for the user after creating 
    869 a playlist: 
     847= 그룹 = 
     848 
     849그룹은 사용자를 분류하는 일반적인 방법입니다. 그룹으로 사용자들을 
     850묶어서 허용권한(permission)을 적용하고 이름을 부여할 수 있습니다. 
     851하나의 사용자는 여러 그룹에 속할 수 있습니다. 
     852 
     853그룹에 포함된 사용자는 자동으로 그 그룹의 허용권한(permission)을 
     854가지게 됩니다. 예를 들어서 {{{Site editors}}}라는 그룹은 
     855{{{can_edit_home_page}}}라는 허용권한(permission)을 가지고 있고 이 
     856그룹에 속한 사용자들도 {{{can_edit_home_page}}} 허용권한(permission)을 
     857부여받게 됩니다. 
     858 
     859허용권한(permission) 이외에 그룹은 사용자들을 쉽게 분류해서 관리할 수 
     860있도록 해줍니다. 예를 들어서 {{{'Special users'}}}라는 그룹을 만들고 
     861사이트에 이 그룹에 속한 사용자들만 접근할 수 있는 페이지를 제공하거나 
     862이 그룹에 속한 사용자들 모두에게 메일을 보낼 수도 있습니다. 
     863 
     864= 메세지 = 
     865 
     866메세지 시스템은 사용자들에게 쉽게 메세지를 보낼 수 있는 큐(queue) 
     867형태의 시스템입니다. (역자주: 장고에서 얘기하는 메세지 시스템은 메일을 
     868발송을 의미하지 않습니다. 장고의 메세지 시스템은 페이지에 간단한 작업 
     869결과 메세지를 표시하는 데 주로 사용됩니다. 아래 예제를 참고하세요.) 
     870 
     871메세지는 {{{User}}} 객체(object)와 묶여 있습니다. 단 메세지를 보낸 
     872시간은 기록하지 않습니다. 
     873 
     874주로 메세지는 장고 관리 페이지에서 어떤 작업을 끝냈을 때 사용됩니다. 
     875예를 들어서 {{{"The poll Foo was created successfully."}}}가 
     876메세지입니다. 
     877 
     878API는 간단합니다.: 
     879 
     880    * {{{user_obj.message_set.create(message='message_text')}}}로 새 
     881    메세지를 만들 수 있습니다. 
     882 
     883    * {{{user_obj.get_and_delete_messages()}}}는 이 
     884    사용자에게 전달된 {{{Message}}}를 리스트(list) 형태로 반환합니다. 
     885 
     886아래 예에서, playlist를 만든 다음 사용자에게 메세지를 남깁니다.: 
    870887{{{ 
    871888def create_playlist(request, songs): 
    872     # Create the playlist with the given songs. 
    873     # ... 
    874     request.user.message_set.create(message="Your playlist was added successfully.") 
     889    # 몇몇 노래로 노래 목록을 만듭니다. 
     890    # ... 
     891    request.user.message_set.create(message="노래 목록을 잘 만들었습니다.") 
    875892    return render_to_response("playlists/create.html", 
    876893        context_instance=RequestContext(request)) 
    877894}}} 
    878 When you use {{{RequestContext}}}, the currently logged-in user and his/her 
    879 messages are made available in the [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py template context] as the template variable 
    880 {{{ {{ messages }} }}}. Here's an example of template code that displays messages: 
     895{{{RequestContext}}}을 사용할 수 있는 상태에서 로그인한 사용자의 
     896메세지는 [wiki:../templates_python/ template context]의 템플릿(template) 변수로 가져올 수 
     897있습니다.: 
    881898{{{ 
    882899{% if messages %} 
     
    888905{% endif %} 
    889906}}} 
    890 Note that {{{RequestContext}}} calls {{{get_and_delete_messages}}} behind the 
    891 scenes, so any messages will be deleted even if you don't display them. 
    892  
    893 Finally, note that this messages framework only works with users in the user 
    894 database. To send messages to anonymous users, use the [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py session framework]. 
    895  
    896  
    897 = Other authentication sources = 
    898  
    899 The authentication that comes with Django is good enough for most common cases, 
    900 but you may have the need to hook into another authentication source - that 
    901 is, another source of usernames and passwords or authentication methods. 
    902  
    903 For example, your company may already have an LDAP setup that stores a username 
    904 and password for every employee. It'd be a hassle for both the network 
    905 administrator and the users themselves if users had separate accounts in LDAP 
    906 and the Django-based applications. 
    907  
    908 So, to handle situations like this, the Django authentication system lets you 
    909 plug in another authentication sources. You can override Django's default 
    910 database-based scheme, or you can use the default system in tandem with other 
    911 systems. 
    912  
    913 == Specifying authentication backends == 
    914  
    915 Behind the scenes, Django maintains a list of "authentication backends" that it 
    916 checks for authentication. When somebody calls 
    917 {{{django.contrib.auth.authenticate()}}} - as described in "How to log a user in" 
    918 above - Django tries authenticating across all of its authentication backends. 
    919 If the first authentication method fails, Django tries the second one, and so 
    920 on, until all backends have been attempted. 
    921  
    922 The list of authentication backends to use is specified in the 
    923 {{{AUTHENTICATION_BACKENDS}}} setting. This should be a tuple of Python path 
    924 names that point to Python classes that know how to authenticate. These classes 
    925 can be anywhere on your Python path. 
    926  
    927 By default, {{{AUTHENTICATION_BACKENDS}}} is set to: 
     907{{{RequestContext}}}는 메세지가 보이는 것과 상관 없이 
     908{{{get_and_delete_messages}}}를 호출해서 사용자에게 할당된 메세지를 
     909지웁니다. 
     910 
     911장고 메세지 시스템은 데이터베이스에 등록된 사용자에게만 사용할 수 
     912있습니다. 등록되지 않은 익명(anonymous) 사용자에게도 적용하고 싶다면 
     913[wiki:../sessions/ session framework]를 활용하는 방법이 있습니다. 
     914 
     915 
     916= 이외 인증과 관련된 소스 = 
     917 
     918장고의 인증 시스템은 대체로 일반적인 요구사항을 만족시키고 있습니다. 
     919하지만, 다른 인증시스템과 연동하는 경우도 있을 수 있습니다. 
     920 
     921예를 들어서, 여러분의 회사가 직원 계정을 LDAP로 관리하고 있는 경우에는 
     922장고 인증시스템과 LDAP에서 각각 계정을 관리하기는 어려울 것입니다. 
     923 
     924그래서 이런 상황을 해결하기 위해서 장고의 인증시스템은 다른 
     925인증시스템을 이용할 수 있는 방법은 제공합니다. 장고의 기본 
     926데이터베이스 구조를 다시 작성하거나 다른 인증시스템과 함께 사용할 수 
     927있습니다. 
     928 
     929== 인증 저장소(authentication backends) == 
     930 
     931장고는 내부적으로 "인증 저장소"의 목록을 가지고 있습니다. 
     932{{{django.contrib.auth.authenticate()}}}가 호출되면 - "로그인시키는 
     933방법은"에서 설명한 것처럼 - 모든 인증 저장소를 사용해서 인증을 
     934시도합니다. 첫번째 저장소(backend)에서 실패하면 다음 번 
     935저장소(backend)로 시도하는 식으로 모든 저장소(backend)를 사용합니다. 
     936 
     937인증 저장소(backend) 목록은 {{{AUTHENTICATION_BACKENDS}}} 설정에 
     938튜플(tuple) 형태로 지정합니다. 
     939 
     940기본적으로, {{{AUTHENTICATION_BACKENDS}}}는: 
    928941{{{ 
    929942('django.contrib.auth.backends.ModelBackend',) 
    930943}}} 
    931 That's the basic authentication scheme that checks the Django users database. 
    932  
    933 The order of {{{AUTHENTICATION_BACKENDS}}} matters, so if the same username and 
    934 password is valid in multiple backends, Django will stop processing at the 
    935 first positive match. 
    936  
    937 == Writing an authentication backend == 
    938  
    939 An authentication backend is a class that implements two methods: 
    940 {{{get_user(user_id)}}} and {{{authenticate(**credentials)}}}. 
    941  
    942 The {{{get_user}}} method takes a {{{user_id}}} - which could be a username, 
    943 database ID or whatever - and returns a {{{User}}} object. 
    944  
    945 The  {{{authenticate}}} method takes credentials as keyword arguments. Most of 
    946 the time, it'll just look like this: 
     944이것은 장고 사용자 데이터베이스를 다루는 기본 인증 
     945저장소(backend)입니다. 
     946 
     947{{{AUTHENTICATION_BACKENDS}}}에서는 순서가 중요합니다. 여러 
     948저장소(backend)에 같은 사용자와 비밀번호가 있는 경우에는, 먼저 인증에 
     949성공하는 저장소(backend)가 사용됩니다. 
     950 
     951== 인증 저장소(authentication backend) 작성하기 == 
     952 
     953인증 저장소(backend)는 두가지 메소드(method)만 구현하면 
     954됩니다:{{{get_user(user_id)}}}, {{{authenticate(**credentials)}}} 
     955 
     956{{{get_user}}} 메소드(method)는 {{{user_id}}}를 인수(argument)도 받아서 
     957{{{User}}}를 반환합니다. - 저장소(backend)에 저장된 사용자 이름입니다. 
     958 
     959{{{authenticate}}} 메소드(method)는 키워드 인수(keyword argument)를 
     960받습니다. 대부분 이런 형태를 보입니다.: 
    947961{{{ 
    948962class MyBackend: 
    949963    def authenticate(self, username=None, password=None): 
    950         # Check the username/password and return a User. 
    951 }}} 
    952 But it could also authenticate a token, like so: 
     964        # username과 password를 검사해서 ``User``를 반환합니다. 
     965}}} 
     966다음처럼 token을 받기도 합니다.: 
    953967{{{ 
    954968class MyBackend: 
    955969    def authenticate(self, token=None): 
    956         # Check the token and return a User. 
    957 }}} 
    958 Either way, {{{authenticate}}} should check the credentials it gets, and it 
    959 should return a {{{User}}} object that matches those credentials, if the 
    960 credentials are valid. If they're not valid, it should return {{{None}}}. 
    961  
    962 The Django admin system is tightly coupled to the Django {{{User}}} object 
    963 described at the beginning of this document. For now, the best way to deal with 
    964 this is to create a Django {{{User}}} object for each user that exists for your 
    965 backend (e.g., in your LDAP directory, your external SQL database, etc.) You 
    966 can either write a script to do this in advance, or your {{{authenticate}}} 
    967 method can do it the first time a user logs in. 
    968  
    969 Here's an example backend that authenticates against a username and password 
    970 variable defined in your {{{settings.py}}} file and creates a Django {{{User}}} 
    971 object the first time a user authenticates: 
     970        # token을 검사해서 ``User``를 반환합니다. 
     971}}} 
     972{{{authenticate}}} 메소드(method)는 인증조건(credentials)을 검사해서 
     973인증을 통과하면 {{{User}}}를, 아니면 {{{None}}}을 반환합니다. 
     974 
     975장고 관리 시스템은 이 문서 처음에서 설명한 것처럼 {{{User}}} 
     976객체(object)와 밀접하게 물려있습니다. 따라서 다른 인증시스템(예를 
     977들어서, LDAP 디렉토리 서비스, 혹은 외부 SQL 데이터베이스)와 연동하기 
     978위해서 가장 좋은 방법은 사용자의 장고의 {{{User}}}객체(object)를 만드는 
     979것입니다. 따라서 따로 스크립트를 작성하거나 사용자가 로그인할 때 
     980{{{authenticate}}} 메소드(method)를 호출해줄 수도 있습니다. 
     981 
     982{{{settings.py}}}에 정의된 사용자와 패스워드로 인증하는 예입니다.: 
    972983{{{ 
    973984from django.conf import settings 
     
    976987class SettingsBackend: 
    977988    """ 
    978     Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD. 
    979  
    980     Use the login name, and a hash of the password. For example: 
     989    ADMIN_LOGIN와 ADMIN_PASSWORD 설정으로 인증을 시도합니다. 
     990 
     991    로그인 이름과 hash처리된 비밀번호를 사용합니다. 예를 들어: 
    981992 
    982993    ADMIN_LOGIN = 'admin' 
     
    9901001                user = User.objects.get(username=username) 
    9911002            except User.DoesNotExist: 
    992                 # Create a new user. Note that we can set password 
    993                 # to anything, because it won't be checked; the password 
    994                 # from settings.py will. 
     1003                # 새로운 사용자를 만듭니다. settings.py에 정의된 
     1004                # 패스워드를 그대로 사용합니다. 
    9951005                user = User(username=username, password='get from settings.py') 
    9961006                user.is_staff = True 
     
    10061016            return None 
    10071017}}} 
    1008 == Handling authorization in custom backends == 
    1009  
    1010 Custom auth backends can provide their own permissions. 
    1011  
    1012 The user model will delegate permission lookup functions 
    1013 ({{{get_group_permissions()}}}, {{{get_all_permissions()}}}, {{{has_perm()}}}, and 
    1014 {{{has_module_perms()}}}) to any authentication backend that implements these 
    1015 functions. 
    1016  
    1017 The permissions given to the user will be the superset of all permissions 
    1018 returned by all backends. That is, Django grants a permission to a user that any 
    1019 one backend grants. 
    1020  
    1021 The simple backend above could implement permissions for the magic admin fairly 
    1022 simply: 
     1018== 다른 인증 저장소(custom backends) 다루기 == 
     1019 
     1020다른 인증 저장소(backend)는 나름대로의 허용권한(permission)을 제공할 
     1021수 있습니다. 
     1022 
     1023user 모델(model)의 허용권한(permission)에 접근하는 
     1024함수(function)들({{{get_group_permissions()}}}, 
     1025{{{get_all_permissions()}}}, {{{has_perm()}}}, 그리고 
     1026{{{has_module_perms()}}})은 인증 저장소(backend)가 구현한 
     1027함수(function)에 의존합니다. 
     1028 
     1029사용자에게 부여된 허용권한(permission)은 모든 저장소(backend)가 가진 
     1030모든 허용권한(permission)의 일부분입니다. 즉, 사용자는 어떤 인증 
     1031저장소(backend)가 허용한다면 허용권한(permission)을 가질 수 있습니다. 
     1032 
     1033간단한 저장소(backend)를 구현한 예입니다. 관리자의 
     1034허용권한(permission)을 검사합니다.: 
    10231035{{{ 
    10241036class SettingsBackend: 
     
    10321044            return False 
    10331045}}} 
    1034 This gives full permissions to the user granted access in the above example. Notice 
    1035 that the backend auth functions all take the user object as an argument, and 
    1036 they also accept the same arguments given to the associated {{{User}}} functions. 
    1037  
    1038 A full authorization implementation can be found in 
    1039 [wiki:http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py django/contrib/auth/backends.py], which is the default backend and queries 
    1040 the {{{auth_permission}}} table most of the time. 
     1046위 예는 관리자에게 모든 허용권한(permission)을 허용합니다. 인증 
     1047저장소(backend)의 함수(function)들은 {{{User}}}객체(object)와 {{{User}}} 
     1048메소드(method)가 받은 인수(argument)를 함께 전달받습니다. 
     1049 
     1050인증에 관해서는 {{{auth_permission}}} 테이블을 사용하는 기본 인증 
     1051저장소(backend)인 {{{django/contrib/auth/backends.py}}}를 참고하세요.