Software Development Engineer

Blog PostsResume

ownCloud 10.0 Feature: Verifying Email addresses

ownCloud lets its users associate an email address with their account. Having an email address gives the users access to various functionalities including, but not limited to password recovery. Versions before 10.0 didn't verify the emails that the users set. This led to many security lapses and also enabled email spamming. If for instance, there is a typo in the email address and the user attempts resetting his password, he would be unable to do so. Also, if a user sets an email address that does not belong to him, he can send spam email to that address by constantly calling for the reset password functionality.

An issue for the request of this enhancement was raised in February 2017 with the issue #7326 and was not solved yet. In the Pull Request (#27277) given to solve the issue, many other subfeatures were added under the guidance of the mentor.

Implementation

Whenever a user sets or changes the email address from his personal settings, an email is sent to that email address with a confirmation link. When the user clicks on this link and is logged into the system, the email sets or changes. If the user is not logged into the system, then he is redirected to the login page and after a successful login, the email is changed. If, in case the logged in user is different that the one who requested an email change, then an exception occurs. An email change notification mail is sent to the previous email address if there was any.

Whenever the email address of a user is changed via the provisional API or by the admin from the users' settings page, the no confirmation is required and the email gets changed.

Various routes were added and there was inclusion of many helpers classes in the settings/UsersController controller. A set/change email button was added to the view and all the notifications were shown using the OC.Notification.showTemporary(...) function.

Functions added

/**
 * @param string $token
 * @param string $userId
 * @throws \Exception
 */
private function checkEmailChangeToken($token, $userId) { ... }

/**
 * @param string $userId
 * @param string $mailAddress
 * @throws \Exception
 * @return boolean
 */
public function sendEmail($userId, $mailAddress) { ... }

/**
 * @param string $id
 * @param string $mailAddress
 */
public function setEmailAddress($id, $mailAddress) { ... }

/**
 * @NoCSRFRequired
 * @NoAdminRequired
 * @NoSubadminRequired
 *
 * @param $token
 * @param $userId
 * @param $mailAddress
 * @return RedirectResponse
 * @throws \Exception
 */
public function changeMail($token, $userId, $mailAddress) { ... }

Functions updated

/**
   * Set the mail address of a user
   *
   * @NoAdminRequired
   * @NoSubadminRequired
   *
   * @param string $id
   * @param string $mailAddress
   * @return DataResponse
   */
  public function setMailAddress($id, $mailAddress) { ... }

Tests

Since there was an addition of various routes and their functions in the systems, the unit tests also require some major changes and updates. More specifically, since an emailChange token was set whenever a user request the change of his email address, tests were added to check for all the cases when the token should or should not be invalid. Also, tests were added to see if the signed in users is the one who requested a change of email address or not. Other small improvements to the existing tests were also added.

Tests added

public function testDifferentLoggedUserAndRequestUser() { ... }

public function testInvalidEmailChangeToken() { ... }

Tests updated

public function testSetEmailAddress($mailAddress, $isValid, $expectsUpdate, $canChangeDisplayName, $responseCode) { ... }

© 2024 Ujjwal Bhardwaj. All Rights Reserved.