[D7] Authy

Thank you for your contribution,

I have noticed a few issues:

hook_install, hook_uninstall, hook_schema should all be in an authy.install file.

In your authy_uninstall() you should remove any variables created by the module, eg: authy_forms, authy_api_key & authy_host_uri.

Do you really need empty hooks such as hook_init, hook_install? these will be called unnecessarily.

Good luck with your module.

Good morning xqus!

I have run PARVIEW, as I noticed you did as well, and it is clean, which is a great start.

In addition to andystone78's review, I would recommend a little more focus on your projects description. Right now, it lists only one sentence, and doesn't provide a lot of information for someone not familiar with authy, or explain why someone might want to use the module.

Regards!

There are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxxqus1722568git

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

> depackage = Security

Typo?

> * Defines the database schema for the module.
* This is used when installing and uninstalling the module.

You can omit this; it's in the docs for the hook.

> * @copyright Copyright (c) Audun Larsen, 2012, 2013

Check guidelines on including authorship in modules. I don't know if there's anything official, but one opinion that's been discussed a lot is that it dissuades other people from contributing code. It also means that should you ever move on and hand the project to someone else, the first thing they have to do is rip out your name, which feels awkward :/

> return user_edit_access($account) && (user_access('administer own authy id') || user_access('administer authy ids'));

Reuse of API functions is good, but I'm concerned that here it makes the logic quite convoluted. I'm still not sure how the 'administer own authy id' permission works. Given that access control is a key part of security, I would opt for repetition and verbosity over reuse. I'd also split the expression into smaller pieces and comment them -- see the coding standards on splitting up expressions.

function authy_user_can_login() {
  return TRUE;
}

??

> function authy_settings($form, &$form_state) {
> function authy_manage($form, &$form_state, $uid) {
> function authy_verify($form, &$form_state) {

This is nitpicky, but it's customary to have a '_form' suffix on form builders. It does make it easier when reading through code to see what a function is for.

Also, this could do to be in an admin.inc file.

 * @return int
 *   Returns a users Authy ID.

... also returns FALSE if nothing found.

  if ($authy === FALSE) {
    return TRUE;
  }

hook_form_alter() shouldn't return anything.

authy_verify_submit and authy_verify_validate are the wrong way round.

> function authy_verify_submit($form, $form_state) {
> function authy_verify_validate($form, $form_state) {

$form_state should be &$form_state in both of these.

> drupal_goto('user');

In a form submit, set $form_state['redirect'].

  global $user;
  $authy_user = $user;

  $authy = _authy_get_api();

  if ($authy_user->uid == 0 && isset($form_state['values']['name'])) {
    $authy_user = user_load_by_name($form_state['values']['name']);
    if ($authy_user === FALSE) {
      $authy_user = user_load_by_mail($form_state['values']['name']);
    }
    if ($authy_user === FALSE) {
      return TRUE;
    }
  }

What's this code doing?
Looks like it's loading a user, but I can't tell which user it might load.

If you're replacing the global $user with something that could potentially be another account, you have a security hole. Remember that $a = $b in PHP is a reference assignment if $b is an object.

> * Post login check to see if user has Authy enabled.

I would say here that's a form validate callback.

> $user = user_load_by_name($form_state['values']['name']);

Don't say $user unless you mean the current user. It's safer to say $account, in case the code should ever get rearranged and end up in the same function as a global $user.

> $form['tan'] = array(

tan?

> Secure your Druapl site with two-factor authentication provided by
> * All users with Authy enabled will be promted for a Authy token on

Typos.

Review of the 7.x-1.x branch:

• Coder Sniffer has found some issues with your code (please check the Drupal coding standards).
  

  FILE: /home/klausi/pareview_temp/authy.forms.inc
  --------------------------------------------------------------------------------
  FOUND 4 ERROR(S) AFFECTING 3 LINE(S)
  --------------------------------------------------------------------------------
    19 | ERROR | If the line declaring an array spans longer than 80 characters,
       |       | each element should be broken into its own line
   208 | ERROR | Spaces must be used to indent lines; tabs are not allowed
   208 | ERROR | Line indented incorrectly; expected 8 spaces, found 7
   209 | ERROR | else must start on a new line
  --------------------------------------------------------------------------------
  
  
  FILE: /home/klausi/pareview_temp/authy.module
  --------------------------------------------------------------------------------
  FOUND 1 ERROR(S) AND 1 WARNING(S) AFFECTING 2 LINE(S)
  --------------------------------------------------------------------------------
    74 | WARNING | Line exceeds 80 characters; contains 81 characters
   277 | ERROR   | If the line declaring an array spans longer than 80
       |         | characters, each element should be broken into its own line
  --------------------------------------------------------------------------------
  

• Codespell has found some spelling errors in your code.
  

  ./authy.forms.inc:182: recieve  ==> receive
  

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. You have to get a review bonus to get a review from me.

manual review:

1. "'access arguments' => array(''),": that should just use TRUE to be more clear that access to anybody is allowed.
2. authy_permission_administer_access(): @param int $account is wrong, this is not an integer?
3. authy_init(): this hook implementation will run on every single page request even if no authentication is going on. Why can't you use a specific page callback? Why do you have to check that on every request?
4. C style comments (/* */) are discouraged within functions (even for multiple lines, repeat the // single-line comment).
5. authy_form_alter(): do not use drupal_add_css() here, but rather the #attached property in the form array. See https://api.drupal.org/api/drupal/developer!topics!forms_api_reference.h... . Same in authy_form_verify() and elsewhere.
6. "// We got the user that is trying to authenticate. Get his uid.": please don't assume that Drupal users are male.
7. _authy_get_authy_id(): Do not use db_select() for simple static queries, use db_query() instead. See http://drupal.org/node/310075
8. _authy_get_api(): doc block is a bit short. What API? An API object? Why is there no @return documentation although the function can return FALSE or an object?
9. form.authy.css and form.authy.js appear to be third party code. Are those exact copies of files that are hosted elsewhere? If you had to modify them please note that in a @file comment (and why you had to do that) and also link to the original source. Since we don't allow unmodified copies of third party code this is a blocker right now.
10. authy_form_manage_submit(): you could use db_merge() instead of delete + insert.
11. authy_init(): doc block is a bit wrong, your are not initialization the lib here?
12. authy_form_alter(): why do you add your authy_login_validate only if you find user_login_final_validate? Please add a comment.
13. authy_form_verify(): shouldn't you only display that form if a user is in the process of token verification? Currently you always display the form, right? I think that should be done in an access callback for the hook_menu() entry.
14. I don't see where you logout the current user if the two factor authentication fails. authy_login_validate() does not prevent the usual user login from succeeding, so the user will be authenticated before the token was entered? Can I just navigate away from the token enter form and I will be logged in? Ah, now I see why you are using hook_init(), to prevent any access to pages as long as the token has not been entered. This is very confusing, as the user system will log a successful login message although the user is not actually able to access pages. I think you should not allow the login process to finish until a token has been entered correctly. So either you display the textfield to enter the token directly on the login form or you redirect away to the token form in your validation callback, storing the user ID in the session. Of course you would you to check form_get_errors() before you do that. Then you also should not need hook_init().

Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

manual review:

• _authy_get_authy_id(): Do not use db_select() for simple static queries, use db_query() instead. See http://drupal.org/node/310075 (very minor).

But otherwise looks RTBC to me!

Assigning to cweagans as he might have time to take a final look at this.

no objections for more than a week, so ...

Thanks for your contribution, xqus!

I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

• Dries' post on Responsible maintainers
• Best practices for creating and maintaining projects
• Maintaining a drupal.org project with Git
• Commit messages - providing history and credit
• Release naming conventions.
• Helping maintainers in the issue queues

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

Thanks to the dedicated reviewer(s) as well.