PageRenderTime 25ms CodeModel.GetById 26ms RepoModel.GetById 1ms app.codeStats 0ms

/docs/quickstart.rst

https://bitbucket.org/andrewlvov/django-registration-custom
ReStructuredText | 287 lines | 212 code | 75 blank | 0 comment | 0 complexity | 43fc389c03bfb2de7149c85b6ce3d49b MD5 | raw file
  1. .. _quickstart:
  2. Quick start guide
  3. =================
  4. Before installing django-registration, you'll need to have a copy of
  5. `Django <http://www.djangoproject.com>`_ already installed. For the
  6. |version| release, Django 1.4 or newer is required.
  7. For further information, consult the `Django download page
  8. <http://www.djangoproject.com/download/>`_, which offers convenient
  9. packaged downloads and installation instructions.
  10. Installing django-registration
  11. ------------------------------
  12. There are several ways to install django-registration:
  13. * Automatically, via a package manager.
  14. * Manually, by downloading a copy of the release package and
  15. installing it yourself.
  16. * Manually, by performing a Mercurial checkout of the latest code.
  17. It is also highly recommended that you learn to use `virtualenv
  18. <http://pypi.python.org/pypi/virtualenv>`_ for development and
  19. deployment of Python software; ``virtualenv`` provides isolated Python
  20. environments into which collections of software (e.g., a copy of
  21. Django, and the necessary settings and applications for deploying a
  22. site) can be installed, without conflicting with other installed
  23. software. This makes installation, testing, management and deployment
  24. far simpler than traditional site-wide installation of Python
  25. packages.
  26. Automatic installation via a package manager
  27. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  28. Several automatic package-installation tools are available for Python;
  29. the recommended one is `pip <http://pip.openplans.org/>`_.
  30. Using ``pip``, type::
  31. pip install django-registration
  32. It is also possible that your operating system distributor provides a
  33. packaged version of django-registration (for example, `Debian
  34. GNU/Linux <http://debian.org/>`_ provides a package, installable via
  35. ``apt-get-install python-django-registration``). Consult your
  36. operating system's package list for details, but be aware that
  37. third-party distributions may be providing older versions of
  38. django-registration, and so you should consult the documentation which
  39. comes with your operating system's package.
  40. Manual installation from a downloaded package
  41. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  42. If you prefer not to use an automated package installer, you can
  43. download a copy of django-registration and install it manually. The
  44. latest release package can be downloaded from `django-registration's
  45. listing on the Python Package Index
  46. <http://pypi.python.org/pypi/django-registration/>`_.
  47. Once you've downloaded the package, unpack it (on most operating
  48. systems, simply double-click; alternately, type ``tar zxvf
  49. django-registration-0.9.tar.gz`` at a command line on Linux, Mac OS X
  50. or other Unix-like systems). This will create the directory
  51. ``django-registration-0.9``, which contains the ``setup.py``
  52. installation script. From a command line in that directory, type::
  53. python setup.py install
  54. Note that on some systems you may need to execute this with
  55. administrative privileges (e.g., ``sudo python setup.py install``).
  56. Manual installation from a Mercurial checkout
  57. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  58. If you'd like to try out the latest in-development code, you can
  59. obtain it from the django-registration repository, which is hosted at
  60. `Bitbucket <http://bitbucket.org/>`_ and uses `Mercurial
  61. <http://www.selenic.com/mercurial/wiki/>`_ for version control. To
  62. obtain the latest code and documentation, you'll need to have
  63. Mercurial installed, at which point you can type::
  64. hg clone http://bitbucket.org/ubernostrum/django-registration/
  65. You can also obtain a copy of a particular release of
  66. django-registration by specifying the ``-r`` argument to ``hg clone``;
  67. each release is given a tag of the form ``vX.Y``, where "X.Y" is the
  68. release number. So, for example, to check out a copy of the |version|
  69. release, type::
  70. hg clone -r v|version| http://bitbucket.org/ubernostrum/django-registration/
  71. In either case, this will create a copy of the django-registration
  72. Mercurial repository on your computer; you can then add the
  73. ``django-registration`` directory inside the checkout your Python
  74. import path, or use the ``setup.py`` script to install as a package.
  75. Basic configuration and use
  76. ---------------------------
  77. Once installed, you can add django-registration to any Django-based
  78. project you're developing. The default setup will enable user
  79. registration with the following workflow:
  80. 1. A user signs up for an account by supplying a username, email
  81. address and password.
  82. 2. From this information, a new ``User`` object is created, with its
  83. ``is_active`` field set to ``False``. Additionally, an activation
  84. key is generated and stored, and an email is sent to the user
  85. containing a link to click to activate the account.
  86. 3. Upon clicking the activation link, the new account is made active
  87. (the ``is_active`` field is set to ``True``); after this, the user
  88. can log in.
  89. Note that the default workflow requires ``django.contrib.auth`` to be
  90. installed, and it is recommended that ``django.contrib.sites`` be
  91. installed as well. You will also need to have a working mail server
  92. (for sending activation emails), and provide Django with the necessary
  93. settings to make use of this mail server (consult `Django's
  94. email-sending documentation
  95. <http://docs.djangoproject.com/en/dev/topics/email/>`_ for details).
  96. Required settings
  97. ~~~~~~~~~~~~~~~~~
  98. Begin by adding ``registration`` to the ``INSTALLED_APPS`` setting of
  99. your project, and specifying one additional setting:
  100. ``ACCOUNT_ACTIVATION_DAYS``
  101. This is the number of days users will have to activate their
  102. accounts after registering. If a user does not activate within
  103. that period, the account will remain permanently inactive and may
  104. be deleted by maintenance scripts provided in django-registration.
  105. For example, you might have something like the following in your
  106. Django settings file::
  107. INSTALLED_APPS = (
  108. 'django.contrib.auth',
  109. 'django.contrib.sites',
  110. 'registration',
  111. # ...other installed applications...
  112. )
  113. ACCOUNT_ACTIVATION_DAYS = 7 # One-week activation window; you may, of course, use a different value.
  114. Once you've done this, run ``manage.py syncdb`` to install the model
  115. used by the default setup.
  116. Setting up URLs
  117. ~~~~~~~~~~~~~~~
  118. The :ref:`default backend <default-backend>` includes a Django
  119. ``URLconf`` which sets up URL patterns for :ref:`the views in
  120. django-registration <views>`, as well as several useful views in
  121. ``django.contrib.auth`` (e.g., login, logout, password
  122. change/reset). This ``URLconf`` can be found at
  123. ``registration.backends.default.urls``, and so can simply be included
  124. in your project's root URL configuration. For example, to place the
  125. URLs under the prefix ``/accounts/``, you could add the following to
  126. your project's root ``URLconf``::
  127. (r'^accounts/', include('registration.backends.default.urls')),
  128. Users would then be able to register by visiting the URL
  129. ``/accounts/register/``, login (once activated) at
  130. ``/accounts/login/``, etc.
  131. Another ``URLConf`` is also provided -- at ``registration.auth_urls``
  132. -- which just handles the Django auth views, should you want to put
  133. those at a different location.
  134. Required templates
  135. ~~~~~~~~~~~~~~~~~~
  136. In the default setup, you will need to create several templates
  137. required by django-registration, and possibly additional templates
  138. required by views in ``django.contrib.auth``. The templates requires
  139. by django-registration are as follows; note that, with the exception
  140. of the templates used for account activation emails, all of these are
  141. rendered using a ``RequestContext`` and so will also receive any
  142. additional variables provided by `context processors
  143. <http://docs.djangoproject.com/en/dev/ref/templates/api/#id1>`_.
  144. **registration/registration_form.html**
  145. Used to show the form users will fill out to register. By default, has
  146. the following context:
  147. ``form``
  148. The registration form. This will be an instance of some subclass
  149. of ``django.forms.Form``; consult `Django's forms documentation
  150. <http://docs.djangoproject.com/en/dev/topics/forms/>`_ for
  151. information on how to display this in a template.
  152. **registration/registration_complete.html**
  153. Used after successful completion of the registration form. This
  154. template has no context variables of its own, and should simply inform
  155. the user that an email containing account-activation information has
  156. been sent.
  157. **registration/activate.html**
  158. Used if account activation fails. With the default setup, has the following context:
  159. ``activation_key``
  160. The activation key used during the activation attempt.
  161. **registration/activation_complete.html**
  162. Used after successful account activation. This template has no context
  163. variables of its own, and should simply inform the user that their
  164. account is now active.
  165. **registration/activation_email_subject.txt**
  166. Used to generate the subject line of the activation email. Because the
  167. subject line of an email must be a single line of text, any output
  168. from this template will be forcibly condensed to a single line before
  169. being used. This template has the following context:
  170. ``activation_key``
  171. The activation key for the new account.
  172. ``expiration_days``
  173. The number of days remaining during which the account may be
  174. activated.
  175. ``site``
  176. An object representing the site on which the user registered;
  177. depending on whether ``django.contrib.sites`` is installed, this
  178. may be an instance of either ``django.contrib.sites.models.Site``
  179. (if the sites application is installed) or
  180. ``django.contrib.sites.models.RequestSite`` (if not). Consult `the
  181. documentation for the Django sites framework
  182. <http://docs.djangoproject.com/en/dev/ref/contrib/sites/>`_ for
  183. details regarding these objects' interfaces.
  184. **registration/activation_email.txt**
  185. Used to generate the body of the activation email. Should display a
  186. link the user can click to activate the account. This template has the
  187. following context:
  188. ``activation_key``
  189. The activation key for the new account.
  190. ``expiration_days``
  191. The number of days remaining during which the account may be
  192. activated.
  193. ``site``
  194. An object representing the site on which the user registered;
  195. depending on whether ``django.contrib.sites`` is installed, this
  196. may be an instance of either ``django.contrib.sites.models.Site``
  197. (if the sites application is installed) or
  198. ``django.contrib.sites.models.RequestSite`` (if not). Consult `the
  199. documentation for the Django sites framework
  200. <http://docs.djangoproject.com/en/dev/ref/contrib/sites/>`_ for
  201. details regarding these objects' interfaces.
  202. Note that the templates used to generate the account activation email
  203. use the extension ``.txt``, not ``.html``. Due to widespread antipathy
  204. toward and interoperability problems with HTML email,
  205. django-registration defaults to plain-text email, and so these
  206. templates should simply output plain text rather than HTML.
  207. To make use of the views from ``django.contrib.auth`` (which are set
  208. up for you by the default URLconf mentioned above), you will also need
  209. to create the templates required by those views. Consult `the
  210. documentation for Django's authentication system
  211. <http://docs.djangoproject.com/en/dev/topics/auth/>`_ for details
  212. regarding these templates.