1286289 - Implement alternate login for testing

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: User management, task, P5)

Description

[John Whitlock [:jwhitlock]]

What problem would this feature solve?
======================================
With bug 1273038, Persona will be removed, first for creating new accounts, and later for logging in as well. Because it is trivial to create a Persona account with a new email, these have been used for automated testing and exploratory testing. Testing will be a lot more difficult when Persona is disabled.

Who has this problem?
=====================
Core contributors to MDN

How do you know that the users identified above have this problem?
==================================================================
After merging of [PR 3901](https://github.com/mozilla/kuma/pull/3901), automated Intern tests began to fail. Soon, we will disable account creation with Persona, and local development will require setting up a GitHub application, and testing multiple users will be more difficult.

How are the users identified above solving this problem now?
============================================================
There are "Advanced" instructions for setting up GitHub for development environments:

https://kuma.readthedocs.io/en/latest/installation.html#advanced-enable-github-auth

Most developers have a single GitHub account, but some have created alternate accounts for testing.

Do you have any suggestions for solving the problem? Please explain in detail.
==============================================================================
Add an alternate login and account creation method using usernames and passwords. Enable this for staging, testing, and development environments, but not for production. Use this for automated testing.

Is there anything else we should know?
======================================
Intern tests are planned to be replaced with new Python / py.test tests, so will probably not be updated for the auth method.

Persona account creation is scheduled for disabling in July 2016.

Persona login on MDN is scheduled for disabling on Nov 1st 2016.

The Persona server is scheduled for disabling on Nov 30th 2016.

Comment 1

[John Whitlock [:jwhitlock]]

It is currently possible for administrators to create and use password-backed accounts:

1. Click "ADD USER" on the user changelist page (https://developer-local.allizom.org/admin/users/user/add/)
2. Enter a username and the password, save it
3. Select "Staff Status" in permissions to set is_staff, save
4. In a new browser, login to the admin with the new user (https://developer-local.allizom.org/admin/login/). You aren't allowed to see anything, but you are now logged in, can get to the site (click VIEW SITE or update your URL), can update your profile, etc.

We may be able to build on that to make it easier to create and use password-backed accounts for testing.  There is a lot of work if we make it a user-facing feature (password resets, adding passwords to social-only accounts, removing your password and making it a social-only account, etc. etc.).

Comment 2

[Matt Brandt [:mbrandt]]

This is a decent start and we can use it for our automated tests. It would be beneficial to be able to generate throw away test accounts on the fly that tests can use when testing new account creation and content editing.

Comment 3

[John Whitlock [:jwhitlock]]

Current status:

• Persona was disabled in 2016, GitHub is the only way for users to signup and login to the site. There was not a significant change in the rate of signups, positive or negative, to justify spending the time to expand the public login options.
• A sample database is used for development, which includes test accounts with known permissions and passwords. This is useful for automated testing, but those tests are rarely used.
• For staging and production, the automated tests are:
  • Django functional and unit tests
  • "headless" tests using the requests library to make HTTP requests without login
  • Selenium tests in Firefox and Chrome without login

There is still not a great way to test either the login process, or tests that require logins, using browsers or automation.

One idea I'm considering is a "test accounts view", that allows logging in as a test user by following a URL. This could be enabled in development and staging, and possibly protected with a secret shared between the testing environment and production, such as a per-deployment environment variable. It would be disallowed in production. This would allow test suites to take action as a logged in user, with a similar security profile to passwords, without requiring a username / password hole in deployed environments.

Lack of automatic testing of logged-in functionality has not been a huge issue. A human tends to notice those issues, or they raise exceptions and are noticed by regular alerting. It would be good to take note when a regression would have been detected by an automated test with login functionality.

Comment 4

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.