Assignment 9: User Accounts, Authentication and Registration

due by 9:00 p.m. EDT on Friday, March 28, 2025

Learning Objectives

After completing this assignment, students will be able to:

• Implement authentication and permissions within a web application.

• Incorporating user accounts into application data models and work flows.

• Revise/refactor URL routing and page views to create a user-based experience.

Pre-requisites: Assignments 8

Assignment 8 builds upon the case study you began in Assignment 5.

You must have completed Assignment 8 before you attempt Assignment 9.

Case Study: Mini Facebook

This assignment is part of an in-depth case study to develop a data-enabled web application. In the entire case-study, you will simulate the core features of the Facebook social networking application:

• Viewing, creating, and updating user profiles
• Viewing and creating status messages
• Uploading images
• Viewing and adding friends
• Developing a news feed to show status messages from multiple friends
• Incorporating user accounts, authentication, and registration

This assignment is the fifth part of the case study, and you will continue the work from the previous assignment to build a database-enabled web application.

Sample Implementation

Here is a sample implementation: MiniFacebook Application.

You do not need to match the data of this example, or even the way it is formatted. The look and feel of the application, as well as the data you display, is entirely up to you.

Preliminaries

In your work on this assignment, make sure to abide by the collaboration policies of the course.

If you have questions while working on this assignment, please post them on Piazza! This is the best way to get a quick response from your classmates and the course staff.

For each problem in this problem set, we will be writing or evaluating some Python code. You are encouraged to use the VS Code IDE which will be discuss/presented in class, but you are welcome to use another IDE if you choose.

Continue working on the mini_fb Application

Continue to do this work within your existing Django project, within the mini_fb. application that you worked on in Assignment 8.

Overview

Django provides many features “out of the box” and ready to use, along with the ability to customize almost everything. One of the great “out of the box” features is the Django User model and authentication framework. The framework comes built-in, ready to use, with generic view classes, templates, and helper functions.

In task 1, we begin by using the authentication framework with an existing user that is already authenticated (logged in).

In task 2, we add login and logout features.

In Task 3, we add registration (creating a User account) to the create Profile process.

Task 1: Authentication with User accounts and constraints on CRUD operations.

1. Modify the Profile model to add a ForeignKey to the standard Django User model (from django.contrib.auth.models). This will associate each Profile with an User for authentication and identification purposes.

   When you make migrations, remember that you will need to set a default value for all existing Profiles – for example, the admin User. You will be able to change this later from the Django Admin pages.

   Note: this will be shown in an in-class example.

2. Use the Django admin to create one non-admin user, and associate it with one of the existing Profiles. This will be your “test” User.

3. Revise the base.html template to account for having an authenticated user.

   It will be helpful to show which user (if any) is logged in while debugging debugging/building the authentication into the application. You can choose whether to keep it in the final version or not.

4. Revise your views to require that a user be logged in before they can do anything that would modify the database, i.e., Create, Update, or Delete operations. The only operations available to a non-logged in user should be showing all profiles, showing a profile page, and creating a new profile.

   Hint: Inherit from the LoginRequiredMixin base class, which will handle the authentication for you.

   Test each view one by one, to ensure that the authentication requirement works as expected. That is to say, try doing an update profile without being logged in. It should fail, and require you to authenticate.

5. Revise the links available from the profile page template. In particular, use decision logic to hide links that should not be available to an unauthenticated User, or when the authenticated User is not the one associated with that Profile.

   That is, the only User who should be allowed to update a profile, create a status message, delete a status message, add friends, or view the news feed is the User associated with the Profile. Other Users, even if they are authenticated, should have “read only” access to this profile page.

6. Test everything! Start at this URL pattern: http://127.0.0.1:8000/mini_fb/.

   Hint:

   It is helpful to test login/logout within “Incognito Mode” in the Chrome Browser. Every new Incognito window is by default not authenticated, and does not remember your previous login. It also makes it possible to be logged in as “Admin” in one window and another user in a different window.

Task 2: Authentication: Login and logout

Django provides a lot of flexibility for authentication. To begin, we will use the built-in authentication framework which can be used directly in your app’s URLs, and is imported from django.contrib.auth.auth_views

1. Add two new URLs to your application:

   a. 'login/', which will be implemented by the auth_views.LoginView

   b. 'logout/', which will be implemented by the auth_views.LogoutView

   Create a URL pattern for each one, with a pseudonym to use within your application.

2. Build the login feature: a tale of three errors and a success.

   a. Test out the URL: http://127.0.0.1:8000/mini_fb/login/.

   It should bring an error message, because it cannot find the default template registration/login.html.

   No worries! Create your own login template at mini_fb/templates/mini_fb/login.html. This template will display a pre-made form, provided by auth_views.LoginView. All you need to do is to create the HTML form tags and a submit button, and display the context variable form.

   In your URL pattern, pass a parameter to the .as_view method, to specify the template name to display, e.g., auth_views.LoginView.as_view(template_name='mini_fb/login.html')

   b. Test out the URL: http://127.0.0.1:8000/mini_fb/login/ again. Fill out the form with username/password and submit.

   This time, expect a page not found error for the URL http://localhost:8000/accounts/login/, which is the default URL within a Django project for the login feature. To provide a specialized login URL, you must implement the get_login_url method on the view class. This method must return the URL to the application’s login (i.e., described in your urlpatterns). Implement this get_login_url method, and ...

   c. Test out the URL: http://127.0.0.1:8000/mini_fb/login/ again. Fill out the form with username/password and submit.

   This time, the login should be successful, but after logging in the default behavior is to direct you to the URL: http://localhost:8000/accounts/profile/. You can verify that the login was successful by trying this URL: http://localhost:8000/mini_fb8/, which should show that you are in fact logged in. The previous problem is that we did not specify what to do after the login was successful. You will correct this by adding a hidden form field in the login form, with the name next, and specify the value to contain a valid URL within your application, for example to show all profiles.

   d. Test out the URL: http://127.0.0.1:8000/mini_fb/login/ again. Fill out the form with username/password and submit.

   This time, you should be logged in AND redirected after login the page identified by the URL in next. Good job.

3. The logout feature is much simpler!

   Test out the URL: http://localhost:8000/mini_fb/logout/.

   Note: in the newest version of Django, the auth_views.LogoutView will not allow a GET request. A link created with the <a> tag always sends a GET request. To send a POST request, you will need to create a small <form> with the method set to POST.

   It should log you out on the first try!

   However, after log out, you are directed to a default “Logged out” page, which is not part of your mini_fb app, does not follow your styling scheme, and contains a link to “Log in again” – to the admin app.

   To customize this behavior, you could create a template mini_fb/templates/mini_fb/logged_out.html which will provide a “log out confirmation” page. Include on this page a link to log in again (to the mini_fb app). To show this template, you will need a simple view (try: TemplateView), and then a URL (e.g., logout_confirmation) to bring up that view.

   In your URL pattern, pass a parameter to the .as_view method, to specify the template name to display, e.g., auth_views.LogoutView.as_view(next_page='logout_confirmation')

   Try logging in again, and logging out again, until you are satisfied that it works.

4. In the base.html template, add navigation links for login and logout.

   Use decision logic to show/hide the navigation URLs depending on which User is logged in.

   That is to say:

   • A user who is not logged in should be able to see all profiles and login.

   • A user who is logged in should have a link to see their own profile page, as well as a link to log out.

5. Now that login and logout work, we will revise some of the application’s URL patterns. These patterns:

   • 'profile/<int:pk>/update'
   • 'profile/<int:pk>/friend_suggestions'
   • 'profile/<int:pk>/news_feed'
   • 'profile/<int:pk>/add_friend/<int:other_pk>'
   • 'profile/<int:pk>/create_status'

   All required a parameter named pk (the primary key) to identify the Profile for which we wanted to do each respective operation. Now that we require a logged in user, we want to change these URLs to:

   • 'profile/update'
   • 'profile/friend_suggestions'
   • 'profile/news_feed'
   • 'profile/add_friend/<int:other_pk>'
   • 'status/create_status'

   That is, to remove the primary key from the URL.

   In the generic view classes, the default way to find the Profile (or any model) object is to use the URL parameter pk to do an object lookup. Now that we have removed the URL parameter pk, we will need a different way to get the object.

   To make this work, revise the view classes that need to find the Profile object by implementing their get_object(self) method (to replace the default behavior). This method implementation will use the logged in user (self.request.user) and the object manager (Profile.objects) to locate and return the Profile corresponding to this User.

   Hint: it will NOT work for Profiles that are still associated with the default User (admin user). There are some simple and some clever work-arounds, and you are welcome to try any reasonable solution. Just be aware that for testing purposes, you should test with a User that is not the admin user.

6. Test everything again!

Task 3: User registration and creating profile

Registration is the process of creating a User account. There are several valid ways to accomplish this and no canonical “correct” solution.

Some options include:

• When a user selects http://127.0.0.1:8000/mini_fb/create_profile, have them register first (fill out the UserCreationForm to create Django User), send them to the login page, and then send them back to the create profile page.

• When a user selects http://127.0.0.1:8000/mini_fb/create_profile, have them register first (fill out the UserCreationForm to create Django User), log them in automatically, and then send them back to the create profile page.

• When a user selects http://127.0.0.1:8000/mini_fb/create_profile, have them fill out two forms at once: the UserCreationForm as well as the CreateProfileForm, and submit both forms at once.

In any of these options, we will need them to be logged in before we process the CreateProfileForm, because we need to set the User as a foreign key on the Profile instance. For simplicity, we will chose the last option: showing the user 2 forms at once, and having them submit both forms together.

Note as well that we do not want to include the User in the CreateProfileForm, as this would create a situation in which the client would pick a User from a drop-down list. Instead, we will assign the User to the profile programmatically.

1. Modify the CreateProfileView class, to add a get_context_data(self, **kwargs: Any) method. This is the method that provides context variables to the template. As you have done before, begin by calling the superclass version of this method, and saving the context dictionary to a local variable.

   Next, create an instance of the UserCreationForm (from django.contrib.auth.forms), and store this instance in the context data. Call it whatever you like, but remember the name so you can find it in the template.

2. Modify your create_profile_form.html template, to display the additional form (UserCreationForm) within the same html form as your CreateProfileForm.

   Test this out in your browser, to see that it displays the fields from the UserCreationForm: Username, Password and Password confirmation, along with the fields from the CreateProfileForm.

3. In the CreateProfileView class’ form_valid method, you will need to:

   • Reconstruct the UserCreationForm instance from the self.request.POST data

   • Call the save() method on the UserCreationForm instance. This method call will return the newly created User object. Save it to a variable.

   • Log the User in (hint: use the built-in function django.contrib.auth.login).

   • Attach the Django User to the Profile instance object (form.instance) so that it can be saved to the database.

   • Delegate the rest to the super class’ form_valid method.

4. Test everything! Start at this URL pattern: http://127.0.0.1:8000/mini_fb/create_profile.

Deployment to cs-webapps

1. Deploy your web application to the cs-webapps.bu.edu.

Follow the [deployment instructions here][deployment].

2. Test your web application on cs-webapps.bu.edu to ensure that everything works correctly.

3. Resolve any deployment issues.

Submitting Your Work

10 points; will be assigned by the autograder, verifying that you have submitted the correct files/URL, and testing that you website exists at the specified URL. 90 points; will be testing your application and code review

Log in to GradeScope to submit your work.

Be sure to name your files correctly!

1. Create a text file within your main django directory called a9_url.txt, containing the URL to your web page, and nothing else.

   For example: https://cs-webapps.bu.edu/azs/cs412/mini_fb/.

   This file will be used by the autograder to locate your web page, so you must get the URL exactly correct, and you must not include any other text or code in the file.

2. Add teaching staff as collaborators to your GitHub repository (wderocco8, Aanuszkiewicz, and azs-bu). Read-only access is fine.

   Create a text file called github_url.txt in the root of your project (e.g., django directory). Paste your GitHub URL in the file.

   Add these files to your git repository using

   `git add -A`.
   

   Commit this to your git repository, using

   `git commit -m "Added a9_url.txt"`
   

   Push it to GitHub, using

   `git push origin main`
   

3. Log in to GradeScope to submit your work.

   In the Gradescope upload page, upload these two files:

   • a9_url.txt

   • github_url.txt

Notes:

• Upload these files to Gradescope before the deadline.

• When you upload, the autograder script will process your file(s).

• You may resubmit as many times as you like before the deadline, and only the grade from the last submission will be counted.