Password reset failed

The password reset link was invalid, possibly because it has already been used. Please request a new password reset. {% Endif%} {% Endblock%} 90053 90283 Password reset complete 90284 90002 This is the last password-reset template, which is displayed to notify you when the password reset has succeeded.Create 90015 /locallibrary/templates/registration/password_reset_complete.html 90016, and give it the following contents: 90005 90044 {% extends «base_generic.html»%} {% Block content%}

The password has been changed!

log in again? {% Endblock%} 90053 90166 Testing the new authentication pages 90167 90002 Now that you’ve added the URL configuration and created all these templates, the authentication pages should now just work! 90005 90002 You can test the new authentication pages by attempting to log in to and then log out of your superuser account using these URLs: 90005 90002 You’ll be able to test the password reset functionality from the link in the login page.90015 Be aware that Django will only send reset emails to addresses (users) that are already stored in its database! 90016 90005 90002 90015 Note 90016: The password reset system requires that your website supports email, which is beyond the scope of this article, so this part 90015 will not work yet 90016. To allow testing, put the following line at the end of your settings.py file. This logs any emails sent to the console (so you can copy the password reset link from the console). 90005 90044 EMAIL_BACKEND = ‘django.core.mail.backends.console.EmailBackend ‘ 90053 90002 For more information, see Sending email (Django docs). 90005 90006 Testing against authenticated users 90007 90002 This section looks at what we can do to selectively control content the user sees based on whether they are logged in or not. 90005 90166 Testing in templates 90167 90002 You can get information about the currently logged in user in templates with the 90009 {{user}} 90010 template variable (this is added to the template context by default when you set up the project as we did in our skeleton).90005 90002 Typically you will first test against the 90009 {{user.is_authenticated}} 90010 template variable to determine whether the user is eligible to see specific content. To demonstrate this, next we’ll update our sidebar to display a «Login» link if the user is logged out, and a «Logout» link if they are logged in. 90005 90002 Open the base template (90015 /locallibrary/catalog/templates/base_generic.html 90016) and copy the following text into the 90009 sidebar 90010 block, immediately before the 90009 endblock 90010 template tag.90005 90044

… 90015 {% if user.is_authenticated%} 90016
• User: 90015 {{user.get_username}} 90016
• Logout 90015 {% else%} 90016
• Login 90015 {% endif%} 90016 90053 90002 As you can see, we use 90009 if 90010 — 90009 else 90010 — 90009 endif 90010 template tags to conditionally display text based on whether 90009 {{user.is_authenticated}} 90010 is true. If the user is authenticated then we know that we have a valid user, so we call 90009 {{user.get_username}} 90010 90015 90016 to display their name. 90005 90002 We create the login and logout link URLs using the 90009 url 90010 template tag and the names of the respective URL configurations. Note also how we have appended 90009? Next = {{request.path}} 90010 to the end of the URLs. What this does is add a URL parameter next containing the address (URL) of the 90003 current 90004 page, to the end of the linked URL.After the user has successfully logged in / out, the views will use this «90009 next 90010» value to redirect the user back to the page where they first clicked the login / logout link. 90005 90002 90015 Note 90016: Try it out! If you’re on the home page and you click Login / Logout in the sidebar, then after the operation completes you should end up back on the same page. 90005 90166 Testing in views 90167 90002 If you’re using function-based views, the easiest way to restrict access to your functions is to apply the 90009 login_required 90010 decorator to your view function, as shown below.If the user is logged in then your view code will execute as normal. If the user is not logged in, this will redirect to the login URL defined in the project settings (90009 settings.LOGIN_URL 90010), passing the current absolute path as the 90009 next 90010 URL parameter. If the user succeeds in logging in then they will be returned back to this page, but this time authenticated. 90005 90044 from django.contrib.auth.decorators import login_required @login_required def my_view (request): … 90053 90002 90015 Note: 90016 You can do the same sort of thing manually by testing on 90009 request.user.is_authenticated 90010, but the decorator is much more convenient! 90005 90002 Similarly, the easiest way to restrict access to logged-in users in your class-based views is to derive from 90009 LoginRequiredMixin 90010. You need to declare this mixin first in the superclass list, before the main view class. 90005 90044 from django.contrib.auth.mixins import LoginRequiredMixin class MyView (LoginRequiredMixin, View): … 90053 90002 This has exactly the same redirect behaviour as the 90009 login_required 90010 decorator. You can also specify an alternative location to redirect the user to if they are not authenticated (90009 login_url 90010), and a URL parameter name instead of «90009 next 90010» to insert the current absolute path (90009 redirect_field_name 90010). 90005 90044 class MyView (LoginRequiredMixin, View): login_url = ‘/ login /’ redirect_field_name = ‘redirect_to’ 90053 90002 For additional detail, check out the Django docs here.90005 90006 Example — listing the current user’s books 90007 90002 Now that we know how to restrict a page to a particular user, let’s create a view of the books that the current user has borrowed. 90005 90002 Unfortunately, we do not yet have any way for users to borrow books! So before we can create the book list we’ll first extend the 90009 BookInstance 90010 model to support the concept of borrowing and use the Django Admin application to loan a number of books to our test user. 90005 90166 Models 90167 90002 First, we’re going to have to make it possible for users to have a 90009 BookInstance 90010 on loan (we already have a 90009 status 90010 and a 90009 due_back 90010 date, but we do not yet have any association between this model and a User.We’ll create one using a 90009 ForeignKey 90010 (one-to-many) field. We also need an easy mechanism to test whether a loaned book is overdue. 90005 90002 Open 90015 catalog / models.py 90016, and import the 90009 User 90010 model from 90009 django.contrib.auth.models 90010 (add this just below the previous import line at the top of the file, so 90009 User 90010 is available to subsequent code that makes use of it): 90005 90044 from django.contrib.auth.models import User 90053 90002 Next, add the 90009 borrower 90010 field to the 90009 BookInstance 90010 model: 90005 90044 borrower = models.ForeignKey (User, on_delete = models.SET_NULL, null = True, blank = True) 90053 90002 While we’re here, let’s add a property that we can call from our templates to tell if a particular book instance is overdue. While we could calculate this in the template itself, using a property as shown below will be much more efficient. 90005 90002 Add this somewhere near the top of the file: 90005 90044 from datetime import date 90053 90002 Now add the following property definition to the 90009 BookInstance 90010 class: 90005 90044 @property def is_overdue (self): if self.due_back and date.today ()> self.due_back: return True return False 90053 90002 90015 Note 90016: We first verify whether 90009 due_back 90010 is empty before making a comparison. An empty 90009 due_back 90010 field would cause Django to throw an error instead of showing the page: empty values ​​are not comparable. This is not something we would want our users to experience! 90005 90002 Now that we’ve updated our models, we’ll need to make fresh migrations on the project and then apply those migrations: 90005 90044 python3 manage.py makemigrations python3 manage.py migrate 90053 90166 Admin 90167 90002 Now open 90015 catalog / admin.py 90016, and add the 90009 borrower 90010 field to the 90009 BookInstanceAdmin 90010 class in both the 90009 list_display 90010 and the 90009 fieldsets 90010 as shown below. This will make the field visible in the Admin section, allowing us to assign a 90009 User 90010 to a 90009 BookInstance 90010 when needed. 90005 90044 @ admin.register (BookInstance) class BookInstanceAdmin (admin.ModelAdmin): list_display = ( ‘book’, ‘status’ 90015, ‘borrower’ 90016, ‘due_back’, ‘id’) list_filter = ( ‘status’, ‘due_back’) fieldsets = ( (None, { ‘Fields’: ( ‘book’, ‘imprint’, ‘id’) }), ( ‘Availability’, { ‘Fields’: ( ‘status’, ‘due_back’ 90015, ‘borrower’ 90016) }), ) 90053 90166 Loan a few books 90167 90002 Now that it’s possible to loan books to a specific user, go and loan out a number of 90009 BookInstance 90010 records.Set their 90009 borrowed 90010 field to your test user, make the 90009 status 90010 «On loan», and set due dates both in the future and the past. 90005 90002 90015 Note 90016: We will not spell the process out, as you already know how to use the Admin site! 90005 90166 On loan view 90167 90002 Now we’ll add a view for getting the list of all books that have been loaned to the current user. We’ll use the same generic class-based list view we’re familiar with, but this time we’ll also import and derive from 90009 LoginRequiredMixin 90010, so that only a logged in user can call this view.We will also choose to declare a 90009 template_name 90010, rather than using the default, because we may end up having a few different lists of BookInstance records, with different views and templates. 90005 90002 Add the following to catalog / views.py: 90005 90044 from django.contrib.auth.mixins import LoginRequiredMixin class LoanedBooksByUserListView (LoginRequiredMixin, generic.ListView): «» «Generic class-based view listing books on loan to current user.» «» model = BookInstance template_name = ‘catalog / bookinstance_list_borrowed_user.html ‘ paginate_by = 10 def get_queryset (self): return BookInstance.objects.filter (borrower = self.request.user) .filter (status__exact = ‘o’). order_by ( ‘due_back’) 90053 90002 In order to restrict our query to just the 90009 BookInstance 90010 objects for the current user, we re-implement 90009 get_queryset () 90010 as shown above. Note that «o» is the stored code for «on loan» and we order by the 90009 due_back 90010 date so that the oldest items are displayed first. 90005 90166 URL conf for on loan books 90167 90002 Now open 90015 / catalog / urls.py 90016 and add a 90009 path () 90010 pointing to the above view (you can just copy the text below to the end of the file). 90005 90044 urlpatterns + = [ path ( ‘mybooks /’, views.LoanedBooksByUserListView.as_view (), name = ‘my-borrowed’), ] 90053 90166 Template for on-loan books 90167 90002 Now, all we need to do for this page is add a template. First, create the template file 90015 /catalog/templates/catalog/bookinstance_list_borrowed_user.html 90016 and give it the following contents: 90005 90044 {% extends «base_generic.html «%} {% Block content%}

  Borrowed books {% If bookinstance_list%}

  {% For bookinst in bookinstance_list%}
  • {{bookinst.book.title}} ({{bookinst.due_back}}) {% Endfor%} {% Else%}

    There are no books borrowed. {% Endif%} {% Endblock%} 90053 90002 This template is very similar to those we’ve created previously for the 90009 Book 90010 and 90009 Author 90010 objects.The only thing «new» here is that we check the method we added in the model 90009 (bookinst.is_overdue 90010) and use it to change the colour of overdue items. 90005 90002 When the development server is running, you should now be able to view the list for a logged in user in your browser at http://127.0.0.1:8000/catalog/mybooks/. Try this out with your user logged in and logged out (in the second case, you should be redirected to the login page). 90005 90002 The very last step is to add a link for this new page into the sidebar.We’ll put this in the same section where we display other information for the logged in user. 90005 90002 Open the base template (90015 /locallibrary/catalog/templates/base_generic.html 90016) and add the line in bold to the sidebar as shown. 90005 90044

    {% If user.is_authenticated%}
    • User: {{user.get_username}} 90015
    • My Borrowed 90016
    • Logout {% Else%}
    • Login {% Endif%} 90053 90166 What does it look like? 90167 90002 When any user is logged in, they’ll see the 90003 My Borrowed 90004 link in the sidebar, and the list of books displayed as below (the first book has no due date, which is a bug we hope to fix in a later tutorial!). 90005 90002 90005 90006 Permissions 90007 90002 Permissions are associated with models and define the operations that can be performed on a model instance by a user who has the permission.By default, Django automatically gives 90003 add 90004, 90003 change 90004, and 90003 delete 90004 permissions to all models, which allow users with the permissions to perform the associated actions via the admin site. You can define your own permissions to models and grant them to specific users. You can also change the permissions associated with different instances of the same model. 90005 90002 Testing on permissions in views and templates is then very similar for testing on the authentication status (and in fact, testing for a permission also tests for authentication).90005 90166 Models 90167 90002 Defining permissions is done on the model «90009 class Meta 90010» section, using the 90009 permissions 90010 field. You can specify as many permissions as you need in a tuple, each permission itself being defined in a nested tuple containing the permission name and permission display value. For example, we might define a permission to allow a user to mark that a book has been returned as shown: 90005 90044 class BookInstance (models.Model): … class Meta: … 90015 permissions = (( «can_mark_returned», «Set book as returned»),) 90016 90053 90002 We could then assign the permission to a «Librarian» group in the Admin site. 90005 90002 Open the 90015 catalog / models.py 90016, and add the permission as shown above. You will need to re-run your migrations (call 90009 python3 manage.py makemigrations 90010 and 90009 python3 manage.py migrate 90010) to update the database appropriately. 90005 90166 Templates 90167 90002 The current user’s permissions are stored in a template variable called 90009 {{perms}} 90010.You can check whether the current user has a particular permission using the specific variable name within the associated Django «app» — e.g. 90009 {{perms.catalog.can_mark_returned}} 90010 will be 90009 True 90010 if the user has this permission, and 90009 False 90010 otherwise. We typically test for the permission using the template 90009 {% if%} 90010 tag as shown: 90005 90044 {% if perms.catalog.can_mark_returned%} {% Endif%} 90053 90166 Views 90167 90002 Permissions can be tested in function view using the 90009 permission_required 90010 decorator or in a class-based view using the 90009 PermissionRequiredMixin 90010. The pattern and behaviour are the same as for login authentication, though of course, you might reasonably have to add multiple permissions. 90005 90002 Function view decorator: 90005 90044 from django.contrib.auth.decorators import permission_required @permission_required ( ‘catalog.can_mark_returned ‘) @permission_required ( ‘catalog.can_edit’) def my_view (request): … 90053 90002 A permission-required mixin for class-based views. 90005 90044 from django.contrib.auth.mixins import PermissionRequiredMixin class MyView (PermissionRequiredMixin, View): permission_required = ‘catalog.can_mark_returned’ # Or multiple permissions permission_required = ( ‘catalog.can_mark_returned’, ‘catalog.can_edit’) # Note that ‘catalog.can_edit’ is just an example # The catalog application does not have such permission! 90053 90166 Example 90167 90002 We will not update the 90003 LocalLibrary 90004 here; perhaps in the next tutorial! 90005 90006 Challenge yourself 90007 90002 Earlier in this article, we showed you how to create a page for the current user listing the books that they have borrowed.The challenge now is to create a similar page that is only visible for librarians, that displays 90003 all 90004 books that have been borrowed, and which includes the name of each borrower. 90005 90002 You should be able to follow the same pattern as for the other view. The main difference is that you’ll need to restrict the view to only librarians. You could do this based on whether the user is a staff member (function decorator: 90009 staff_member_required 90010, template variable: 90009 user.is_staff 90010) but we recommend that you instead use the 90009 can_mark_returned 90010 permission and 90009 PermissionRequiredMixin 90010, as described in the previous section. 90005 90002 90015 Important 90016: Remember not to use your superuser for permissions based testing (permission checks always return true for superusers, even if a permission has not yet been defined!). Instead, create a librarian user, and add the required capability. 90005 90002 When you are finished, your page should look something like the screenshot below.90005 90002 90005 90006 Summary 90007 90002 Excellent work — you’ve now created a website that library members can log in into and view their own content and that librarians (with the correct permission) can use to view all loaned books and their borrowers. At the moment we’re still just viewing content, but the same principles and techniques are used when you want to start modifying and adding data. 90005 90002 In our next article, we’ll look at how you can use Django forms to collect user input, and then start modifying some of our stored data.90005 90006 See also 90007 90006 In this module 90007 .90000 HTTP authentication — Web technology for developers 90001 90002 HTTP provides a general framework for access control and authentication. This page is an introduction to the HTTP framework for authentication, and shows how to restrict access to your server using the HTTP «Basic» schema. 90003 90004 The general HTTP authentication framework 90005 90002 RFC 7235 defines the HTTP authentication framework, which can be used by a server to challenge a client request, and by a client to provide authentication information.90003 90002 The challenge and response flow works like this: 90003 90010 90011 The server responds to a client with a 90012 401 90013 (Unauthorized) response status and provides information on how to authorize with a 90012 WWW-Authenticate 90013 response header containing at least one challenge. 90016 90011 A client that wants to authenticate itself with the server can then do so by including an 90012 Authorization 90013 request header with the credentials. 90016 90011 Usually a client will present a password prompt to the user and will then issue the request including the correct 90012 Authorization 90013 header.90016 90025 90002 90003 90002 In the case of a «Basic» authentication like shown in the figure, the exchange 90029 must 90030 happen over an HTTPS (TLS) connection to be secure. 90003 90032 Proxy authentication 90033 90002 The same challenge and response mechanism can be used for 90035 proxy authentication 90036. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes is needed. In the case of proxies, the challenging status code is 90012 407 90013 (Proxy Authentication Required), the 90012 Proxy-Authenticate 90013 response header contains at least one challenge applicable to the proxy, and the 90012 Proxy-Authorization 90013 request header is used for providing the credentials to the proxy server.90003 90032 Access forbidden 90033 90002 If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the 90012 403 90013 90012 Forbidden 90013 status code. Unlike 90012 401 90013 90012 Unauthorized 90013 or 90012 407 90013 90012 Proxy Authentication Required 90013, authentication is impossible for this user. 90003 90032 Authentication of cross-origin images 90033 90002 A potential security hole recently been fixed by browsers is authentication of cross-site images.From Firefox 59 onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs (bug 1423146), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page. 90003 90032 Character encoding of HTTP authentication 90033 90002 Browsers use 90012 utf-8 90013 encoding for usernames and passwords. 90003 90002 Firefox once used 90012 ISO-8859-1 90013, but changed to 90012 utf-8 90013 for parity with other browsers and to avoid potential problems as described in bug 1419658.90003 90032 WWW-Authenticate and Proxy-Authenticate headers 90033 90002 The 90012 WWW-Authenticate 90013 and 90012 Proxy-Authenticate 90013 response headers define the authentication method that should be used to gain access to a resource. They must specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials. 90003 90002 The syntax for these headers is the following: 90003 90086 WWW-Authenticate: realm = Proxy-Authenticate: realm = 90087 90002 Here, 90012 90013 is the authentication scheme ( «Basic» is the most common scheme and introduced below).The 90035 realm 90036 is used to describe the protected area or to indicate the scope of protection. This could be a message like «Access to the staging site» or similar, so that the user knows to which space they are trying to get access to. 90003 90032 Authorization and Proxy-Authorization headers 90033 90002 The 90012 Authorization 90013 and 90012 Proxy-Authorization 90013 request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the 90012 90013 is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.90003 90086 Authorization: Proxy-Authorization: 90087 90032 Authentication schemes 90033 90002 The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software. 90003 90002 The most common authentication scheme is the «Basic» authentication scheme, which is introduced in more detail below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS.Common authentication schemes include: 90003 90112 90113 90029 Basic 90030 90116 90117 See RFC 7617, base64-encoded credentials. More information below. 90118 90113 90029 Bearer 90030 90116 90117 See RFC 6750, bearer tokens to access OAuth 2.0-protected resources 90118 90113 90029 Digest 90030 90116 90117 See RFC 7616, only md5 hashing is supported in Firefox, see bug 472823 for SHA encryption support 90118 90113 90029 HOBA 90030 90116 90117 See RFC 7486, Section 3, 90029 H 90030 TTP 90029 O 90030 rigin- 90029 B 90030 ound 90029 A 90030 uthentication, digital-signature-based 90118 90113 90029 Mutual 90030 90116 90117 See RFC 8120 90118 90113 90029 AWS4-HMAC-SHA256 90030 90116 90117 See AWS docs 90118 90157 90004 Basic authentication scheme 90005 90002 The «Basic» HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID / password pairs, encoded using base64.90003 90032 Security of basic authentication 90033 90002 As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme 90029 is not secure 90030. HTTPS / TLS should be used with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information. 90003 90032 Restricting access with Apache and basic authentication 90033 90002 To password-protect a directory on an Apache server, you will need a 90012.htaccess 90013 and a 90012 .htpasswd 90013 file. 90003 90002 The 90012 .htaccess 90013 file typically looks like this: 90003 90086 AuthType Basic AuthName «Access to the staging site» AuthUserFile /path/to/.htpasswd Require valid-user 90087 90002 The 90012 .htaccess 90013 file references a 90012 .htpasswd 90013 file in which each line consists of a username and a password separated by a colon (90012: 90013). You can not see the actual passwords as they are encrypted (md5 in this case).Note that you can name your 90012 .htpasswd 90013 file differently if you like, but keep in mind this file should not be accessible to anyone. (Apache is usually configured to prevent access to 90012 .ht * 90013 files). 90003 90086 aladdin: $ apr1 $ ZjTqBB3f $ IF9gdYAGlMrs2fuINjHsz. user2: $ apr1 $ O04r.y2H $ / vEkesPhVInBByJUkXitA / 90087 90032 Restricting access with nginx and basic authentication 90033 90002 For nginx, you will need to specify a location that you are going to protect and the 90012 auth_basic 90013 directive that provides the name to the password-protected area.The 90012 auth_basic_user_file 90013 directive then points to a 90012 .htpasswd 90013 file containing the encrypted user credentials, just like in the Apache example above. 90003 90086 location / status { auth_basic «Access to the staging site»; auth_basic_user_file /etc/apache2/.htpasswd; } 90087 90032 Access using credentials in the URL 90033 90002 Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this: 90003 90086 https: // username: password @ www.example.com/ 90087 90002 90029 The use of these URLs is deprecated 90030. In Chrome, the 90012 username: password @ 90013 part in URLs is even stripped out for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt «You are about to log in to the site» www.example.com «with the username» username «, but the website does not require authentication. This may be an attempt to trick you. » 90003 90004 See also 90005 .

      Добавить комментарий Отменить ответ

      Ваш адрес email не будет опубликован. Обязательные поля помечены *

      Комментарий *

      Имя *

      Email *

      Сайт