We recently saw a scenario where the client wanted to create an ip whitelist for their intranet site. This site is the same installation as the client’s public site. It simply has a different domain and different content. The question was ‘How we can manage separate whitelists and blacklists (ie ‘list sets’) for each domain, rather than one list set per installation.’

This module solves that issue. It is functionally a combination of two existing modules: ‘Ip_ranges’ ( http://drupal.org/project/ip_ranges ) and ‘domain_access’ (http://drupal.org/project/domain).
Domain_ip depends on Domain Access.

Domain_ip behaves similarly to ip_ranges, but it differs in the following ways:

  • Ip_ranges is used to define an ip whitelist and blacklist for a specific site. This is okay except for installations that also use the domain_access module, because they have different domains for a same installation. In this case, they are restricted to single list sets across domains. Whereas ip_ranges works against all domains for an installation, domain_ip provides a separate list set for each domain, respectively, meaning each domain has its own independent whitelist and blacklist.
  • To manage multiple sites, on the administration page there is a separate ip settings tab for each list set. Each domain has its own administration tab.
  • domain_ip uses either a whitelist or a blacklist, not both. This means that only one list is being used at a time. An administrator could switch between lists to either the whitelist or the blacklist. If a domain uses the whitelist, only ips in whitelist could access this domain. All other ips will be banned. Even if the ip is also in the blacklist. If a domain uses blacklist, all ips in blacklist will be banned, even if the ip is also in the whitelist. By default, domain_ip uses the blacklist, the blacklist being blank. So, no ip is being banned initially.
  • Domain ip provides an ip owner field to correspond with the numeric ip. By associating an ip with its owner, ips can be recognized by other administrators easily. For dynamic ips, they are best handled by manually removing them.
  • Administrators of domain_ip can customize messages shown to restricted visitors.

Note: Many users have dynamic ips. This means they can be arbitrarily given access or banned, simply because their ips have changed.

Git link:
git clone http://git.drupal.org/sandbox/smiletrl/1795244.git domain_ip

Project page:
http://drupal.org/sandbox/smiletrl/1795244

This module is developed for drupal 7.

Reviews of other projects:
http://drupal.org/node/1837812#comment-6721244
http://drupal.org/node/1833682#comment-6723394
https://drupal.org/node/1838490#comment-6725112

Second reviews of other projects:
http://drupal.org/node/1844398#comment-6762314
http://drupal.org/node/1833682#comment-6723578
https://drupal.org/node/1838490#comment-6733246

CommentFileSizeAuthor
domain_ip.jpg6.98 KBsmiletrl

Comments

smiletrl’s picture

Issue summary: View changes

delete redundant

  • tag
  • vaibhavjain’s picture

    Status: Needs review » Needs work

    Hello,

    Here is the review

    .info file
    files[] = domain_ip.module
    This should not be posted here, check this - http://drupal.org/node/542202
    Only extra files should be added to info file.

    .module file
    @file declaration is missing
    Missing comments for - function domain_ip_whitelist_own_address, domain_ip_switch_list

    .admin.inc file
    domain_ip_form - Not sure on this, but I believe you need not to mention

    $form['#validate'][] = 'domain_ip_form_validate';
    $form['#submit'][] = 'domain_ip_form_submit';

    Drupal will by default hit these functions, if names are not mentioned. Please check, on this, if this works, you save on extra code.

    elseif ($ip_start == ip_address() || ($ip_end && domain_ip_check_range($ip_start . '-' . $ip_end, ip_address()))) {
      // This fires if users own IP is in the selected range. Currently we wont do anything in that case.
     }

    What are we doing in this function, this can work, but hopefully you will add some activity. :)

    Line 147 - return;, why do we do that ?

    Apart from all this, there are some minor formatting issues, check here - http://ventral.org/pareview/httpgitdrupalorgsandboxsmiletrl1795244git

    Also, to fasten the Review process, please read - https://drupal.org/node/1410826 - and gain a review bonus :)

    smiletrl’s picture

    Hi, vaibhavjain,
    Thank you very much for your review. The links you provided are very helpful.
    Yeah, I tried to review other applications. But, to be honestly, I don't have much knowledge about this. In other words, I'm not sure whether other's code is clean or safe. There're guidelines in drupal.org, I just lose my patience to read one word by one word. Yeah, I really should look at this.
    Thanks again for your great help~

    smiletrl’s picture

    Issue summary: View changes

    Add notes about whitelist

    smiletrl’s picture

    Status: Needs work » Needs review
    Issue tags: +PAreview: review bonus

    Please review this, thank you:)

    cubeinspire’s picture

    Status: Needs review » Needs work
    Issue tags: +PAreview: security

    Welcome Smiletrl and thank you for helping on the review process !

    Automatic review

    All seems ok ok.

    Manual review

    1. There is an XSS vulnerability on the display of the banned message.
    If you set this as message an alert is displayed when banned. <script>alert('hello');</script>
    Please check that all user entered content is sanitized on output.

    function domain_ip_deny_access($domain_name) {
      header($_SERVER['SERVER_PROTOCOL'] . ' 403 Forbidden');
      $message = variable_get('Banned_IP_error_message', 'Sorry, you are banned for this site.');
      print $message;
      exit();
    }
    


    I've found another issue but it's related to the domain module not the domain_ip module...


    ** At the page admin/structure/domain when clicking on edit domain i'm redirected to another domain name... I've made a local installation with three domain names at /etc/hosts pointing to the same folder files to test this module. Then I blacklisted my self from one of the domain names. When I enter to edit the setup using a domain name where I'm not blacklisted and click on domain name I'm redirected to localhost (without the global $base_url so to a 404 page).

    Except issue 1 the code is clean from what I saw.
    Just correct this XSS problem and I guess this module is ready to RTBC.

    smiletrl’s picture

    Hi logicdesign,

    Thanks for your review.

    I've made changes for xss vulnerability like this:

    function domain_ip_deny_access($domain_name) {
      header($_SERVER['SERVER_PROTOCOL'] . ' 403 Forbidden');
      $message = variable_get('Banned_IP_error_message', 'Sorry, you are banned for this site.');
      print check_plain($message);
      exit();
    }

    For the other issue you mentioned, I can't reproduce it on my computer or the server. Do all these three domains work fine without domain ip module? And, have you made the Apache Virtualhost settings, so these domains will all point to the same drupal folder?

    smiletrl’s picture

    Status: Needs work » Needs review

    Needs review. Thanks:)

    smiletrl’s picture

    Status: Needs review » Needs work

    Sorry, I fond some translate issues.

    smiletrl’s picture

    Status: Needs work » Needs review

    Please review this. Thank you:)

    smiletrl’s picture

    Issue summary: View changes

    Add review comment.

    klausi’s picture

    Status: Needs review » Reviewed & tested by the community
    Issue tags: -PAreview: review bonus

    manual review:

    1. domain_ip_deny_access(): is that function really necessary? You could simply use drupal_access_denied().
    2. domain_ip_deny_access(): also that does not even return valid HTML? And you should use drupal_exit() instead of exit.
    3. "'#title' => 'Your name',": all user facing text must run through t() for translation.
    4. domain_ip_restriction_page(): $ip->author is user provided text and should be sanitized before printing. I could not exploit that because the textfield is limited to 15 characters, but you should take care of it anyway. See also http://drupal.org/node/28984
    5. you could add a check for the user's IP adress in a validation function and display a confirmation form if ip_address() is in the blacklist range.
    6. "array('@list' => check_plain($list))": that check_plain() is not necessary since the "@" placeholder will do the sanitization fro you.
    7. quite a few spelling and grammar errors here and there, I would recommend proof reading from a native english speaker. Also sentences in ALL CAPS are hard to read and annoying.

    But that are not hard blockers, otherwise looks RTBC to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

    klausi’s picture

    Issue summary: View changes

    Remove some text.

    smiletrl’s picture

    Issue summary: View changes

    English spelling

    smiletrl’s picture

    Issue tags: +PAreview: review bonus

    Hi klausi,
    Thanks for your review!
    Here're the things to your review:

    1. domain_ip_deny_access() is not a page callback. It's used to end the page request in bootstrap phase. That's the reason why it doesn't return HTML. Also because this function is called at bootstrap phase, many drupal functions or modules haven't got loaded, so functions like drupal_access_denied(), and drupal_exit() are not available in this context.

    2.Fixed the sanitization and translate issues.

    3.It's a good idea to show user a confirm form before they add their own ip into blacklist. So, I've made changes to validation function and if the condition happens, this form will terminate submission and get rebuilt with a checkbox, requiring user to confirm that he/her really wants to add own ip into blacklist.

    4. Made English changes to the project description.

    Please check this. Thank you:)

    klausi’s picture

    Status: Reviewed & tested by the community » Fixed

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

    Thanks for your contribution, smiletrl!

    I updated your account to let you 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:

    You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and get 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.

    smiletrl’s picture

    Hi klausi,
    Thank you!
    I've learned a lot from this review process, and I'd like to join the reviewer group!

    Automatically closed -- issue fixed for 2 weeks with no activity.

    Anonymous’s picture

    Issue summary: View changes

    format issue