Django Module 6
Authentication and authorization interview questions
Interview questions on authentication and authorization: warm-ups, then what each harder question tests and how a good answer starts.
Warm-up questions
Short questions with short answers, each answered in full.
-
Fresher
Why does Django's logout need a POST request?
-
Fresher to mid
What are USERNAME_FIELD and REQUIRED_FIELDS for on a custom user model?
-
Fresher
What is the difference between a model permission and an object-level permission in Django?
Answered in the lesson Permissions, groups and object-level access
-
Fresher
Why does Django store passwords as slow, salted hashes?
Answered in the lesson Password hashing, lockouts, MFA and social login
Questions with model answers
What each question tests, the first step of a good answer and the follow-ups to expect.
-
Fresher to senior
A resident's phone was stolen while she was signed in to Nivas. From her laptop she changes her password. Is the stolen phone still signed in? Explain what Django does, what it leaves to you, and what you would add.
- What it tests
- How Django ties each session to the password hash, what update_session_auth_hash() keeps, and how to end every session of an account on purpose.
- First step
- Follow the phone's next request: AuthenticationMiddleware loads the user from the session and compares the hash stored there with a hash of the current password. Then ask which view changed the password, and whether it kept only the laptop's session with update_session_auth_hash().
- Follow-ups
-
- What if the password is changed by a view you wrote yourself?
- How do you sign out every device without a password change?
- What does rotating SECRET_KEY do to the sessions?
From the lesson Login, logout and password reset
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
-
Mid to senior
Support asks for the password reset page to say "We have no account with that email", to cut down on tickets. What do you tell them, and what do you build instead?
- What it tests
- Account enumeration through messages and timing, weighing it against support load, and alternatives that help real residents without telling strangers which addresses have accounts.
- First step
- Say what the message would reveal: anyone could type an address and learn whether it has an account on Nivas, which helps phishing and password guessing. Then describe what Django does now: the same 302 and page for every address, and an email only when an active account uses it.
- Follow-ups
-
- The sign-up form says "This email is already registered". Is that the same problem?
- How do you remove the difference in response time?
- How do you cut the tickets without the message?
From the lesson Login, logout and password reset
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to staff
A two-year-old project has 40,000 users on Django's own auth.User and twelve apps with foreign keys to it. The business now wants phone-number sign-in. Do you move to a custom user model? If so, how, without losing users or sessions; if not, what do you do instead?
- What it tests
- Why AUTH_USER_MODEL cannot simply change after migrate, the options with their costs, and a migration plan that keeps data, keys and sign-ins working.
- First step
- Separate the goal from the mechanism: phone sign-in needs a unique, normalised phone per user and a backend, not necessarily a new user model. Then cost the swap honestly: every foreign key, the migration history of every app, and a release in which nobody may sign up.
- Follow-ups
-
- What is the smallest change that gives phone sign-in?
- How do you swap the model while keeping the same table?
- How do you prove nothing was lost after the release?
From the lesson A custom user model from day one
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Fresher to senior
Residents of a society portal sign in with their mobile numbers, stored as typed. Support finds people with two accounts, one as "98000 00001" and one as "+91 98000-00001", each with its own bills. How did it happen, how do you repair the data, and how do you stop it for good?
- What it tests
- Normalising identifiers before a unique constraint, merging duplicate accounts with their related rows, and enforcing one form at every entry point.
- First step
- Group the existing phones by their normalised E.164 form and count the groups with more than one account. That is the size of the repair, and the proof that the unique constraint held spellings, not people.
- Follow-ups
-
- Which of the two accounts survives the merge?
- What else must move with the merged account?
- Where must the normalising happen so that no path skips it?
From the lesson A custom user model from day one
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A resident reports that changing the number in /complaints/412/ shows other flats' complaints, with names and phone numbers. The portal is in production. What do you do in the first hour, in the first day, and to stop the same hole from appearing in another view?
- What it tests
- Treating broken access control as an incident: containment, the fix by queryset scoping, finding similar views, tests that fail on the hole, and what the logs can tell about exposure.
- First step
- Contain before you investigate: deploy the scoped lookup for that view, or take the page down, within the hour. Then confirm the cause in the code: a lookup by primary key alone, get_object_or_404(Complaint, pk=pk), with only @login_required in front of it.
- Follow-ups
-
- How do you find every other view with the same hole?
- What can the logs tell you about who saw what?
- Should the page answer 403 or 404 for someone else's complaint?
From the lesson Permissions, groups and object-level access
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
Nivas grows to serve societies with several towers. Each tower has its own committee, which may see and mark the bills of its tower only, and a society treasurer sees every tower. Design the permissions, groups and querysets, and say what you test.
- What it tests
- Separating what a role may do from where it applies, modelling scope as data, keeping list and detail checks in one place, and an access test matrix.
- First step
- Split the rule in two: the action (see bills, mark them paid) is a model permission held by a role; the place (which tower) is data, a membership linking a person to a tower in a role. Check that model permissions alone cannot say "tower B only".
- Follow-ups
-
- Why not one group per tower?
- Where does the tower check go for marking a bill paid?
- How do you keep the admin from showing other towers?
From the lesson Permissions, groups and object-level access
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
Nivas has 12,000 residents with PBKDF2 hashes, and the society wants them all on Argon2 within a month. Hashes upgrade only at sign-in, and a third of the residents have not signed in for a year. How do you get every hash onto Argon2, and what do you check?
- What it tests
- How Django upgrades hashes, why a rehash needs the password, the wrapped-hasher migration for accounts that never sign in, and the risks of a mixed set of hashes.
- First step
- Put Argon2PasswordHasher first and keep PBKDF2 below it, so active residents move at their next sign-in. Then count hashes by algorithm with a query on the password field's prefix, to see how many will never move on their own.
- Follow-ups
-
- Why can Django not simply rehash every stored password tonight?
- What do the residents who never return cost you if you leave them?
- How do you size Argon2's memory and time on your servers?
From the lesson Password hashing, lockouts, MFA and social login
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to staff
Committee members can mark bills as paid, so the society wants a second factor compulsory for them and optional for other residents. Design it with django-otp: setting up a device, enforcing it, a lost phone, and what you test.
- What it tests
- Enforcing a second factor per role, TOTP set-up and recovery, OTPMiddleware and is_verified(), and keeping the recovery path from becoming the weak point.
- First step
- Decide where enforcement lives: every view that only the committee may use checks request.user.is_verified(), which OTPMiddleware sets, beside the permission. Then plan set-up as a step that a committee member cannot skip before reaching those views.
- Follow-ups
-
- A committee member loses their phone on the day bills are due. What happens?
- Would you allow SMS codes as the second factor?
- How do you test that no committee view works without the second factor?
From the lesson Password hashing, lockouts, MFA and social login
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes